ISO 27001 SoA a NIS2- és DORA-felkészültséghez

Hétfő reggel 08:30 van, és Elena, egy gyorsan növekvő B2B FinTech SaaS-szolgáltató információbiztonsági vezetője (CISO), megnyit egy sürgősként megjelölt igazgatósági kérést. A vállalat nemrég megszerezte az ISO/IEC 27001:2022 tanúsítást, de egy jelentős uniós banki érdeklődő a szokásos biztonsági kérdőívnél lényegesen mélyebb kérdéseket tesz fel.

Nem csupán arra kíváncsiak, hogy a vállalat titkosítja-e az adatokat, használ-e többtényezős hitelesítést, vagy rendelkezik-e penetrációs tesztelési jelentéssel. Azt akarják tudni, hogy a SaaS-platform támogatja-e a DORA szerinti kötelezettségeiket, a szolgáltató NIS2 hatálya alá kerülhet-e IKT-szolgáltatásként vagy digitális infrastruktúra-függőségként, és az ISO 27001 alkalmazhatósági nyilatkozat képes-e minden bevont kontrollt, minden kizárt kontrollt és minden bizonyítékot megindokolni.

Az igazgatóság azt a kérdést teszi fel, amelyet minden CISO, megfelelőségi vezető és SaaS-alapító egyre gyakrabban hall:

Igazolhatja-e az ISO 27001 SoA a NIS2- és DORA-felkészültségünket?

Elena tudja, hogy rossz válasz lenne három külön megfelelési programot indítani: egyet az ISO 27001, egyet a NIS2, egyet pedig a DORA számára. Ez duplikált bizonyítékokat, ütköző kontrollfelelősöket és minden ügyfélértékelés előtt állandó kapkodást eredményezne. A jobb válasz az, ha a meglévő IBIR válik a megfelelés működési rendszerévé, az alkalmazhatósági nyilatkozat – vagy SoA – pedig a központi visszakövethetőségi dokumentummá.

A SoA nem pusztán egy táblázat az ISO-tanúsításhoz. Az uniós kiberbiztonsági és operatív reziliencia-környezetben ez az a dokumentum, amelyben a szervezet igazolja, miért léteznek a kontrollok, miért védhetők a kizárások, ki felel az egyes kontrollokért, milyen bizonyítékok támasztják alá a bevezetést, és a kontrollkészlet hogyan kezeli a NIS2, DORA, GDPR, ügyfélszerződések és belső kockázatkezelés követelményeit.

A Clarysec vállalati Információbiztonsági szabályzata Információbiztonsági szabályzat kimondja:

Az IBIR-nek tartalmaznia kell a meghatározott alkalmazási terület határait, a kockázatértékelési módszertant, a mérhető célkitűzéseket, valamint az alkalmazhatósági nyilatkozatban (SoA) indokolt dokumentált kontrollokat.

Ez a követelmény az Információbiztonsági szabályzat 6.1.2 pontjából származik, és az auditkész megközelítés alapja. A SoA-nak híddá kell válnia a kötelezettségek, kockázatok, kontrollok, bizonyítékok és vezetői döntések között.

Miért változtatta meg a NIS2 és a DORA az „alkalmazható” jelentését

Egy hagyományos ISO/IEC 27001:2022 SoA gyakran egyszerű kérdéssel indul: „Mely A melléklet szerinti kontrollok alkalmazandók a kockázatkezelési tervünkre?” Ez továbbra is helyes, de SaaS-, felhő-, menedzselt szolgáltatási, fintech-, pénzügyi technológiai és kritikus ellátási láncban működő szolgáltatók számára már nem elegendő.

A NIS2 megemeli a kiberbiztonsági kockázatkezelés alapkövetelményeit az EU-ban működő alapvető és fontos szervezetek számára. Olyan ágazatokat fed le, mint a digitális infrastruktúra, a felhőszolgáltatók, az adatközponti szolgáltatók, a tartalomkézbesítő hálózatok, a menedzselt szolgáltatók, a menedzselt biztonsági szolgáltatók, a banki szektor és a pénzügyi piaci infrastruktúrák. A tagállamoknak azonosítaniuk kell az alapvető és fontos szervezeteket, valamint a domainnév-regisztrációs szolgáltatókat; sok olyan technológiai szolgáltató pedig, amely korábban a kiberbiztonsági szabályozást ügyféloldali kérdésként kezelte, ma már vagy közvetlenül hatály alá kerül, vagy szerződéses továbbhárítási követelményeken keresztül érintett.

A NIS2 Article 21 megfelelő és arányos technikai, működési és szervezeti intézkedéseket ír elő a kockázatelemzés, biztonsági szabályzatok, incidenskezelés, üzletmenet-folytonosság, ellátási lánc biztonsága, biztonságos beszerzés és fejlesztés, kontrollhatékonyság-értékelés, kiberhigiénia, képzés, kriptográfia, HR-biztonság, hozzáférés-szabályozás, eszközkezelés és – ahol indokolt – hitelesítés területén. A NIS2 Article 23 lépcsőzetes incidensjelentési elvárásokat ad hozzá, beleértve a korai figyelmeztetést, a bejelentést, a frissítéseket és a jelentős incidensekre vonatkozó végleges jelentést.

A DORA, vagyis a Digital Operational Resilience Act 2025. január 17-től alkalmazandó, és a pénzügyi szervezetekre, valamint azok IKT-kockázati ökoszisztémájára összpontosít. Lefedi az IKT-kockázatkezelést, az IKT-val kapcsolatos incidensjelentést, bizonyos szervezeteknél a működési vagy biztonsági fizetési incidensek jelentését, a digitális operatív reziliencia tesztelését, a kiberfenyegetettségi információk megosztását, az IKT harmadik fél kockázatkezelést, a szerződéses megállapodásokat és a kritikus IKT harmadik fél szolgáltatók felügyeletét.

Azoknál a pénzügyi szervezeteknél, amelyek a NIS2 alapján is alapvető vagy fontos szervezetnek minősülnek, a DORA ágazatspecifikus rezsimként működik az egyenértékű IKT-kockázatkezelési és incidensjelentési kötelezettségekre. A pénzügyi ügyfeleket kiszolgáló SaaS-szolgáltatók, felhőszolgáltatók, MSP-k és MDR-szolgáltatók esetében azonban a gyakorlati valóság az, hogy a DORA elvárásai beszerzésen, szerződéseken, auditálási jogokon, incidens-támogatási kötelezettségeken, kilépési tervezésen, alvállalkozói átláthatóságon és rezilienciát alátámasztó bizonyítékokon keresztül jelennek meg.

Ez megváltoztatja a SoA-ról szóló beszélgetést. A kérdés már nem az, hogy „Tartalmazza-e ezt a kontrollt az A melléklet?” A jobb kérdés a következő:

Igazolni tudjuk-e, hogy a kontrollkiválasztás kockázatalapú, figyelembe veszi a kötelezettségeket, arányos, felelőshöz rendelt, bevezetett, nyomon követett, bizonyított és jóváhagyott?

Az ISO 27001 mint a NIS2 és DORA univerzális fordítója

Az ISO/IEC 27001:2022 azért értékes, mert irányítási rendszerszabvány, nem szűk ellenőrzőlista. Megköveteli, hogy az IBIR beépüljön a szervezeti folyamatokba, és igazodjon a szervezet igényeihez. Ez teszi hatékony univerzális fordítóvá az egymást átfedő megfelelési követelmények között.

A 4.1–4.4 pontok előírják, hogy a szervezet értse meg a kontextusát, azonosítsa az érdekelt feleket, határozza meg a releváns követelményeket, és definiálja az IBIR alkalmazási területét. Egy Elena vállalatához hasonló FinTech SaaS-szolgáltató esetében ezek az érdekelt felekhez kapcsolódó követelmények magukban foglalhatják az uniós ügyfeleket, a DORA által érintett pénzügyi ügyfeleket, a NIS2 ágazati kitettséget, a GDPR szerinti adatkezelői és adatfeldolgozói kötelezettségeket, a kiszervezett felhőfüggőségeket, a beszállítói interfészeket és az igazgatósági elvárásokat.

A 6.1.1–6.1.3 pontok megkövetelik a kockázatokra és lehetőségekre vonatkozó tervezést, az ismételhető információbiztonsági kockázatértékelési folyamatot, a kockázatkezelési folyamatot, az A melléklettel való összevetést, valamint az alkalmazhatósági nyilatkozatot, amely azonosítja a bevont kontrollokat, a bevezetési állapotot és a kizárások indoklását.

Itt válik a SoA kontrolldöntési nyilvántartássá. Egy kontroll bevonható azért, mert kockázatot kezel, jogi követelményt teljesít, ügyfélszerződést elégít ki, üzleti célkitűzést támogat, vagy alapvető biztonsági higiéniai elvárást képvisel. Kontrollt kizárni csak akkor lehet, ha a szervezet tudatosan értékelte azt, az IBIR alkalmazási területe szempontjából irrelevánsnak találta, dokumentálta az indoklást, és megszerezte a megfelelő jóváhagyást.

A Clarysec vállalati Kockázatkezelési szabályzata Kockázatkezelési szabályzat kimondja:

Az alkalmazhatósági nyilatkozatnak (SoA) tükröznie kell minden kockázatkezelési döntést, és frissíteni kell minden alkalommal, amikor a kontrolllefedettség módosul.

Ez a követelmény a Kockázatkezelési szabályzat 5.4 pontjából kritikus a NIS2- és DORA-felkészültséghez. Egy új szabályozott ügyfél, új felhőfüggőség, új incidensjelentési kötelezettség vagy új beszállítói koncentrációs kockázat mind módosíthatja a kontroll alkalmazhatóságát.

Ne a kontrolllistával, hanem a megfelelőségi nyilvántartással kezdjen

A gyenge SoA az A melléklettel kezd, és azt kérdezi: „Mely kontrolljaink vannak már meg?” Az erős SoA a szervezet működési valóságából indul ki, és azt kérdezi: „Mely kötelezettségeket, szolgáltatásokat, kockázatokat, adatokat, beszállítókat és ügyfeleket kell az IBIR-nek kezelnie?”

Az ISO/IEC 27005:2022 ezt a megközelítést támogatja azzal, hogy hangsúlyozza az érdekelt felek követelményeit, a kockázati kritériumokat, valamint a szabványok, belső szabályok, törvények, jogszabályok, szerződések és meglévő kontrollok figyelembevételének szükségességét. Azt is kiemeli, hogy az alkalmazhatatlanságot vagy meg nem felelést magyarázni és indokolni kell.

A Clarysec KKV-k számára készült Jogi és szabályozói megfelelési szabályzat-sme Jogi és szabályozói megfelelési szabályzat-sme - KKV ugyanezt a működési elvet rögzíti:

Az ügyvezetőnek egyszerű, strukturált megfelelési nyilvántartást kell fenntartania, amely tartalmazza:

Ez a követelmény a Jogi és szabályozói megfelelési szabályzat-sme 5.1.1 pontjából származik. Egy kisebb szervezetnél a nyilvántartás lehet egyszerű. Egy nagyvállalatnál részletesebbnek kell lennie. A logika ugyanaz: a kötelezettségeknek láthatónak kell lenniük, mielőtt leképezhetők lennének.

A Clarysec vállalati Jogi és szabályozói megfelelési szabályzata Jogi és szabályozói megfelelési szabályzat egyértelműen fogalmaz:

Minden jogi és szabályozási kötelezettséget konkrét szabályzatokhoz, kontrollokhoz és felelősökhöz kell rendelni az információbiztonság-irányítási rendszerben (IBIR).

Ez a Jogi és szabályozói megfelelési szabályzat 6.2.1 pontja. Ez adja az irányítási gerincet ahhoz, hogy az ISO 27001 alkalmazhatósági nyilatkozatot a NIS2- és DORA-megfelelési felkészültséghez használják.

Olyan kockázati kritériumokat alakítson ki, amelyek tükrözik a rezilienciát, az adatvédelmet, a beszállítókat és a szabályozást

Sok SoA-indoklás azért bukik el, mert a kockázati pontozási modell túl szűk. Túlzottan a technikai valószínűségre és hatásra épít, de nem ragadja meg a szabályozási kitettséget, a szolgáltatáskritikusságot, az ügyfélkárt, a beszállítói függőséget, az adatvédelmi hatást vagy a rendszerszintű működési zavart.

A NIS2 nem csak a bizalmasságról szól. Arra összpontosít, hogy megelőzze és minimalizálja az incidensek szolgáltatásokra és szolgáltatást igénybe vevőkre gyakorolt hatását. A DORA a kritikus vagy fontos funkciókat az alapján határozza meg, hogy a zavar lényegesen rontaná-e a pénzügyi teljesítményt, a szolgáltatás-folytonosságot vagy a jogszabályi megfelelést. A GDPR hozzáadja az elszámoltathatóságot, a sértetlenséget, a bizalmasságot, az adatsértési felkészültséget és az érintetteket érő kárt.

A Clarysec KKV-k számára készült Kockázatkezelési szabályzat-sme Kockázatkezelési szabályzat-sme - KKV gyakorlati minimumot ad:

Minden kockázati bejegyzésnek tartalmaznia kell: leírás, valószínűség, hatás, pontszám, felelős és kezelési terv.

Ez a Kockázatkezelési szabályzat-sme 5.1.2 pontja. A NIS2- és DORA-felkészültséghez a Clarysec ezt a minimumot olyan mezőkkel bővíti ki, mint a kötelezettség forrása, érintett szolgáltatás, adatkategória, beszállítói függőség, üzleti felelős, szabályozási hatás, maradványkockázat, kezelési állapot és bizonyítékforrás.

Figyelje meg a megfogalmazást. Az erős indoklás nem csak annyit mond, hogy „bevezetve”. Megmagyarázza, miért alkalmazható a kontroll a szervezet üzleti, szabályozási és kockázati kontextusában.

Képezze le a NIS2- és DORA-területeket az ISO 27001:2022 kontrollokra

Miután a megfelelőségi nyilvántartás és a kockázati kritériumok rendelkezésre állnak, a gyakorlati feladat a szabályozási területek A melléklet szerinti kontrollokra történő leképezése. Ez a leképezés önmagában nem igazolja a megfelelést, de az auditoroknak és ügyfeleknek világos irányt ad a bizonyítékok teszteléséhez.

Elena számára ez a leképezés megváltoztatta az igazgatósági beszélgetést. Ahelyett, hogy a NIS2-t és a DORA-t külön projektként mutatta volna be, láthatóvá tette az átfedést: irányítás, kockázatkezelés, incidensek, folytonosság, beszállítók, tesztelés, hozzáférés-szabályozás és kriptográfia.

A három ISO-kontroll, amelytől minden NIS2- és DORA-SoA függ

A Zenith Controls: The Cross-Compliance Guide Zenith Controls kiadványban a Clarysec három ISO/IEC 27002:2022 kontrollt tekint központinak a NIS2 és DORA szempontjából auditkész SoA-irányításban. Ezek ISO-kontrollok, amelyeket a Zenith Controls útmutató keresztmegfelelési attribútumokkal egészít ki.

Ezek a kontrollok nem elszigeteltek. Közvetlenül kapcsolódnak az A.5.19–A.5.23 beszállítói kapcsolati kontrollokhoz, az A.5.24–A.5.28 incidenskezelési kontrollokhoz, az A.5.29 és A.5.30 folytonossági kontrollokhoz, az A.5.34 adatvédelmi kontrollhoz, az A.8.8 sérülékenységkezeléshez, az A.8.9 konfigurációkezeléshez, az A.8.13 információbiztonsági mentéshez, az A.8.15 naplózáshoz, az A.8.16 felügyeleti tevékenységekhez, az A.8.24 kriptográfiához, az A.8.25–A.8.29 biztonságos fejlesztési kontrollokhoz és az A.8.32 változáskezeléshez.

A Zenith Controls értéke abban áll, hogy segít a csapatoknak elkerülni, hogy a SoA-t egyetlen szabványhoz kötött artefaktumként kezeljék. Az 5.31 kontroll támogatja a jogi és szerződéses leképezést. Az 5.35 kontroll támogatja a belső auditot, a független felülvizsgálatot és a vezetői bizonyosságot. Az 5.36 kontroll támogatja a szabályzatoknak, eljárásoknak, szabványoknak és kontrollkövetelményeknek való működési megfelelést.

Használja a Zenith Blueprintet a SoA kialakítására, tesztelésére és megvédésére

A Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint kiadványban a Clarysec a SoA kialakítását a kockázatkezelési szakaszba helyezi, a 13. lépéshez: kockázatkezelési tervezés és alkalmazhatósági nyilatkozat. A Blueprint arra utasítja a szervezeteket, hogy használják a „Risk Register and SoA Builder.xlsx” sablon SoA-munkalapját, döntsenek arról, hogy a 93 A melléklet szerinti kontroll mindegyike alkalmazható-e, és a döntést a kockázatkezelésre, jogi és szerződéses követelményekre, hatálybeli relevanciára és szervezeti kontextusra alapozzák.

A Blueprint kimondja:

A SoA gyakorlatilag összekötő dokumentum: összekapcsolja a kockázatértékelést/-kezelést a ténylegesen meglévő kontrollokkal.

Ez a mondat foglalja össze a működési modellt. A SoA összeköti a kötelezettségeket, kockázatokat, szabályzatokat, kontrollokat, bizonyítékokat és auditkövetkeztetéseket.

A Zenith Blueprint azt is előírja a csapatoknak, hogy ahol indokolt, a SoA megjegyzéseiben hivatkozzanak a szabályozásokra. Ha egy kontrollt GDPR, NIS2 vagy DORA miatt vezettek be, ennek meg kell jelennie a kockázati nyilvántartásban vagy a SoA megjegyzéseiben. Később, a 24. lépésben a Blueprint előírja a szervezeteknek, hogy a bevezetést követően frissítsék a SoA-t, és ellenőrizzék keresztben a kockázatkezelési tervvel. A 30. lépésben – tanúsítási felkészülés, végső felülvizsgálat és próbaaudit – a Blueprint arra irányítja a csapatokat, hogy erősítsék meg: minden alkalmazható A melléklet szerinti kontrollhoz rendelkezésre áll bizonyíték, például szabályzat, eljárás, jelentés, terv vagy bevezetési bejegyzés.

Ez a sorrend a SoA-t élő megfelelési eszközzé teszi:

1. A 13. lépés a kockázatkezelésből és a kötelezettségekből építi fel.
2. A 24. lépés a bevezetés tényleges állapotához méri.
3. A 30. lépés a végső bizonyíték-felülvizsgálaton és próbaauditon keresztül védi meg.

Hogyan írjon olyan bevonási indoklásokat, amelyeket az auditorok követni tudnak

Egy kontrollt akkor kell bevonni, ha legalább egy védhető hajtóerő fennáll: kockázatkezelés, jogi követelmény, szerződéses követelmény, hatálybeli relevancia, alapvető biztonsági higiénia, ügyfélbizonyossági elvárás vagy vezetés által jóváhagyott reziliencia-célkitűzés.

Hasznos képlet:

Alkalmazható, mert [kockázat vagy kötelezettség] érinti a(z) [szolgáltatást, eszközt, adatot vagy folyamatot], és ez a kontroll [megelőző, észlelő, helyesbítő vagy reziliencia-eredményt] biztosít, amelyet [szabályzat, bejegyzés, teszt, jelentés vagy rendszerkimenet] bizonyít.

Egy fintech SaaS-szolgáltató esetében egy SoA-sor például így nézhet ki:

Ez azért alkalmas auditra, mert összekapcsolja a kontrollt a kontextussal, kockázattal, kötelezettséggel, bevezetéssel, felelősséggel és bizonyítékkal.

Hogyan indokolja a kizárásokat auditkitettség létrehozása nélkül

A kizárások nem hibák. A rosszul indokolt kizárások hibák.

Az ISO/IEC 27001:2022 előírja, hogy a SoA indokolja a kizárt A melléklet szerinti kontrollokat. Az ISO/IEC 27005:2022 megerősíti, hogy az alkalmazhatatlanságot magyarázni és indokolni kell. A Clarysec vállalati Információbiztonsági szabályzata kimondja:

Az alapvonal testreszabható; a kizárásokat azonban formális jóváhagyással és indoklással kell dokumentálni a SoA-ban.

Ez az Információbiztonsági szabályzat 7.2.2 pontja.

A Clarysec Információbiztonsági szabályzat-sme Információbiztonsági szabályzat-sme - KKV kimondja:

A jelen szabályzattól való bármely eltérést dokumentálni kell, világosan bemutatva, miért szükséges az eltérés, milyen alternatív védelmi intézkedések vannak érvényben, és melyik dátumra van meghatározva az ismételt értékelés.

Ez a követelmény az Információbiztonsági szabályzat-sme 7.2.1 pontjából származik.

A NIS2 és DORA esetében a kizárások különös körültekintést igényelnek. Egy SaaS-vállalatnak ritkán indokolt kizárnia a naplózást, a felügyeletet, a biztonsági mentéseket, az incidenskezelést, a hozzáférés-szabályozást, a beszállítói biztonságot vagy a sérülékenységkezelést. Még ha egy kontroll nem is kapcsolódik egyetlen konkrét kockázathoz, szükséges lehet alapvető biztonsági higiénia, ügyfélbizonyosság, szerződéses elvárás vagy jogi kötelezettség miatt.

A Clarysec Kockázatkezelési szabályzat-sme arra is emlékezteti a csapatokat, hogyan kell kezelni az elfogadott kockázatot:

Elfogadás: Indokolja, miért nincs szükség további intézkedésre, és rögzítse a maradványkockázatot.

Ez a Kockázatkezelési szabályzat-sme 6.1.1 pontja, és pontosan ez a szemlélet szükséges a kizárásokhoz és a maradványkockázati döntésekhez.

Incidensjelentés: a munkafolyamatot igazolja, ne a szabályzat létezését

A NIS2 Article 23 lépcsőzetes jelentős incidensjelentést ír elő, beleértve a tudomásszerzéstől számított 24 órán belüli korai figyelmeztetést, a 72 órán belüli bejelentést, a kért frissítéseket és a 72 órás bejelentéstől számított egy hónapon belüli végleges jelentést. A DORA megköveteli a pénzügyi szervezetektől a jelentős IKT-val kapcsolatos incidensek észlelését, kezelését, osztályozását, eszkalációját, kommunikálását és jelentését, az érintett ügyfelek tájékoztatását, ahol szükséges, a gyökérok-elemzés elvégzését és a kontrollok fejlesztését.

Egy SaaS-szolgáltató nem mindig jelent közvetlenül DORA-hatóságnak, de szükséges lehet, hogy támogassa pénzügyi ügyfelei jelentéstételi határidőit. Ez az incidenskontrollokat kiemelten relevánssá teszi a SoA-ban.

A gyenge SoA ezt mondja: „Létezik incidensreagálási szabályzat.”

Az erős SoA ezt mondja: „Alkalmazható, mert a szervezetnek észlelnie, értékelnie, osztályoznia, eszkalálnia, kommunikálnia, bizonyítékot megőriznie, szabályozott jelentéstételi határidőket támogatnia, szerződéses kötelezettség esetén érintett ügyfeleket értesítenie, és tanulnia kell a szolgáltatásokat, adatokat vagy szabályozott ügyfeleket érintő incidensekből.”

A bizonyítékoknak tartalmazniuk kell:

• Incidensreagálási tervet és eszkalációs mátrixot.
• Súlyossági besorolási kritériumokat.
• Ügyfélértesítési munkafolyamatot.
• Szabályozó hatósági értesítési döntési fát, ahol alkalmazható.
• Incidensjegyeket és incidens-idővonalakat.
• Naplókat és felügyeleti riasztásokat.
• Asztali gyakorlatok nyilvántartásait.
• Incidens utáni felülvizsgálatot és helyesbítő intézkedéseket.
• Bizonyítékmegőrzési eljárásokat.

A Clarysec vállalati Audit- és megfelelésfelügyeleti szabályzata Audit- és megfelelésfelügyeleti szabályzat megmagyarázza, miért fontos ez:

Igazolható bizonyító anyagok és auditnyom előállítása szabályozó hatósági megkeresések, jogi eljárások vagy ügyfélbizonyossági igények támogatására.

Ez a cél az Audit- és megfelelésfelügyeleti szabályzat 3.4 pontjából származik.

Kisebb szervezeteknél a bizonyítékok megőrzését is egyértelműen rögzíteni kell. A Clarysec Audit- és megfelelésfelügyeleti szabályzat-sme Audit- és megfelelésfelügyeleti szabályzat-sme - KKV kimondja:

A bizonyítékokat legalább két évig meg kell őrizni, vagy tovább, ha azt tanúsítási vagy ügyfélmegállapodások előírják.

Ez az Audit- és megfelelésfelügyeleti szabályzat-sme 6.2.4 pontja.

Egy SoA, több auditbeszélgetés

A legjobb SoA nem duplikál keretrendszereket. Visszakövethető kontroll-narratívát hoz létre, amelyet különböző auditorok is megértenek.

Egy ISO 27001 auditor általában a pontok logikájával kezd: alkalmazási terület, érdekelt felek, kockázatértékelés, kockázatkezelés, SoA, célkitűzések, belső audit, vezetőségi felülvizsgálat és fejlesztés. Egy NIS2-orientált felülvizsgáló az arányosságra, a vezetői elszámoltathatóságra, a képzésre, az ellátási láncra, az incidens-határidőkre és a szolgáltatási hatásra összpontosít. Egy DORA-orientált ügyfélértékelő az IKT-kockázatra, a kritikus vagy fontos funkciókra, a jelentős IKT-incidensekre, a rezilienciatesztelésre, a szerződéses záradékokra, auditálási jogokra, kilépési tervekre, alvállalkozásba adásra és koncentrációs kockázatra figyel. Egy adatvédelmi felülvizsgáló a GDPR szerinti elszámoltathatóságra és adatsértési felkészültségre fókuszál. Egy COBIT 2019 vagy ISACA-stílusú auditor az irányítást, mutatókat, tulajdonosi felelősségeket, bizonyosságot és helyesbítő intézkedéseket teszteli.

Ezért a SoA-t nem tarthatja karban kizárólag a biztonsági csapat. Jogi, adatvédelmi, beszerzési, mérnöki, üzemeltetési, HR- és felsővezetői tulajdonosi felelősségre is szükség van.

Gyakori SoA-hibák NIS2- és DORA-felkészültségi projektekben

A Clarysec ismétlődően ugyanazokat a problémákat látja a felkészültségi projektekben:

1. A SoA alkalmazhatónak jelöl kontrollokat, de nincs rögzítve kockázat, kötelezettség vagy üzleti indok.
2. A NIS2 és a DORA szerepel a szabályzatokban, de nincs leképezve kontrollokra, felelősökre vagy bizonyítékokra.
3. A beszállítói kontrollok bevezetettként vannak jelölve, de nincs beszállítói nyilvántartás, kritikussági besorolás, szerződéses felülvizsgálat vagy kilépési terv.
4. Az incidenskontrollok léteznek, de a folyamat nem támogatja a 24 órás, 72 órás, ügyféloldali vagy végleges jelentéstételi munkafolyamatokat.
5. A vezetői jóváhagyás hallgatólagos, de nincs bejegyzés a kockázatelfogadásról, a SoA jóváhagyásáról vagy a maradványkockázati döntésről.
6. A kizárásokat sablonból másolják, és nem illeszkednek a tényleges felhő-, távmunka-, SaaS- vagy fintech működési modellhez.
7. A bizonyítékok különböző eszközökben léteznek, de nincs auditnyom, amely összekapcsolná a bizonyítékokat a SoA-val.
8. A GDPR szerinti személyes adatok kezelése nincs összekapcsolva a biztonsági kontrollokkal, az adatsértések kezelésével, a beszállítói szerződésekkel vagy a megőrzéssel.
9. A belső audit dokumentumokat ellenőriz, de nem teszteli, hogy a SoA tükrözi-e a tényleges bevezetést.
10. A SoA-t csak a tanúsítás előtt frissítik, nem pedig új ügyfelek, beszállítók, incidensek, auditmegállapítások vagy szabályozási változások után.

Ezek nem adminisztratív problémák. Ezek irányítási problémák.

Gyakorlati ellenőrzőlista auditkész ISO 27001 SoA-hoz

Használja ezt az ellenőrzőlistát ISO 27001 tanúsítási audit, NIS2-felkészültségi felülvizsgálat, DORA ügyfélértékelés, igazgatósági ülés vagy befektetői kellő gondossági folyamat előtt.

Alakítsa a SoA-t védhető megfelelési híddá

Elena igazgatósági prezentációja azért volt sikeres, mert nem három egymástól elszigetelt megfelelési projektet mutatott be. Egy kontrollált, bizonyítékalapú működési modellt mutatott be, amely az ISO/IEC 27001:2022-re épült, és amelyben a SoA híd a szabályozás, a kockázat, a kontrollbevezetés, a bizonyítékok és a vezetői felügyelet között.

A NIS2 és a DORA nem teszi elavulttá az ISO 27001-et. Értékesebbé teszik a jól felépített ISO 27001 alkalmazhatósági nyilatkozatot. A SoA lehet az egyetlen hely, ahol a szervezet elmagyarázza, miért léteznek a kontrollok, miért védhetők a kizárások, hogyan őrzi meg a bizonyítékokat, hogyan irányítja a beszállítókat, hogyan eszkalálja az incidenseket, és honnan tudja a vezetés, hogy az IBIR működik.

Az azonnali teendő egyszerű:

1. Nyissa meg a jelenlegi SoA-t.
2. Válasszon ki öt alkalmazhatónak jelölt kontrollt, és tegye fel a kérdést: „Milyen kockázat, kötelezettség vagy szerződés indokolja ezt?”
3. Válasszon ki öt kizárást, és tegye fel a kérdést: „Ez továbbra is védhető lenne egy NIS2-, DORA-, GDPR- vagy ISO/IEC 27001:2022 auditor előtt?”
4. Ellenőrizze, hogy minden alkalmazható kontrollhoz van-e aktuális bizonyíték.
5. Erősítse meg, hogy a vezetés jóváhagyta a maradványkockázatokat és a SoA-döntéseket.
6. Frissítse a megfelelőségi nyilvántartást, a kockázati nyilvántartást és a SoA-t minden alkalommal, amikor szolgáltatások, beszállítók, ügyfelek, szabályozások vagy incidensek változnak.

A Clarysec ebben a Zenith Blueprint Zenith Blueprint, a Zenith Controls Zenith Controls, vállalati és KKV-s szabályzatkészletek, kockázati nyilvántartási eszközök, SoA-sablonok, auditfelkészítés és keresztmegfelelési leképezés révén segíti a szervezeteket a NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 és ügyfélbizonyossági követelményekhez.

Ha a SoA nem tud válaszolni arra, miért létezik egy kontroll, ki felel érte, milyen bizonyíték igazolja, és mely kötelezettséget támogatja, akkor még nem áll készen. Használja a Clarysecet, hogy auditkész megfelelési híddá alakítsa, mielőtt egy szabályozó hatóság, auditor vagy ügyfél először feltenné ugyanezeket a kérdéseket.