ISO 27001 szerinti IBIR-hatókör NIS2, DORA és GDPR megfeleléshez

Maria, egy gyorsan növekvő európai fintech vállalat CISO-ja úgy gondolta, hogy az ISO 27001 felügyeleti audit kézben van.

A tanúsítvány friss volt. Az Alkalmazhatósági Nyilatkozat érettnek tűnt. A hatókörnyilatkozat lefedte „a SaaS platform működését támogató vállalati információbiztonság-irányítási rendszert”. Az éles felhőkörnyezet dokumentálva volt. Létezett incidensreagálási eljárás. A kockázati nyilvántartásban szerepeltek kockázatgazdák, dátumok és maradványkockázati besorolások.

Ekkor az auditor feltett egy egyszerű kérdést:

„A SaaS platform mely részei tartoznak egyúttal a NIS2 regisztráció hatókörébe, mely kiszervezett szolgáltatások támogatják a pénzügyi ügyfelek DORA szerinti kritikus vagy fontos funkcióit, és pontosan hol történik GDPR szerinti személyesadat-kezelés?”

A teremben csend lett.

A jogi terület megnyitott egy táblázatot a szabályozási kötelezettségekről. A termékcsapat elővett egy architektúraábrát. A DPO megnyitotta az adatkezelési tevékenységek nyilvántartását. A beszerzés elővette a beszállítói listát. Az üzemeltetés megnyitotta a katasztrófa-helyreállítási tervet. Egyik sem illeszkedett a másikhoz.

Az IBIR hatóköre azt mondta: „SaaS platform”. A NIS2 értékelés több tagállamban digitális infrastruktúra-szolgáltatásokat azonosított. Az ügyfélszerződések a platformot szabályozott pénzügyi műveleteket támogató szolgáltatásként írták le. A GDPR nyilvántartások identitásadatokat, telemetriát, IP-címeket, fizetési metaadatokat, támogatási jegyeket és alvállalkozóhoz kiszervezett analitikát tartalmaztak. A katasztrófa-helyreállítási terv lefedte az éles környezetet, de nem azt az ügyféltámogatási platformot, amelyet a személyesadat-sértéssel kapcsolatos kommunikációhoz használtak. A beszállítói átvilágítás lefedte a tárhelyszolgáltatót, de nem az éles naplókhoz kapcsolódó menedzselt detektálási szolgáltatást.

Ez a 2026-os IBIR-hatókör-meghatározási probléma. Az ISO 27001 tanúsítás továbbra is értékes, de a szűk „minimálisan életképes hatókör” kockázattá válhat, ha a felügyeletek, ügyfelek és auditorok ugyanattól az irányítási rendszertől várják el a NIS2 szerinti alapvető szolgáltatások, a DORA szerinti kritikus vagy fontos funkciók és a GDPR szerinti adatkezelési határok magyarázatát.

Az ISO/IEC 27001:2022, a NIS2, a DORA és a GDPR esetében a gyenge hatókör nem adminisztratív hiányosság. Ez az első dominó. Ha a hatókör hibás, a kockázatértékelés hiányos, a SoA félrevezető, a beszállítói kontrollok nem fedik le a kritikus szolgáltatókat, az incidensbejelentési határidők bizonytalanná válnak, és az adatvédelmi elszámoltathatóság csapatokra töredezik.

Miért vált az ISO 27001 szerinti IBIR-hatókör szabályozási határrá?

Az ISO/IEC 27001:2022 4.3 pontja előírja, hogy a szervezet határozza meg az IBIR határait és alkalmazhatóságát, figyelembe véve a belső és külső tényezőket, az érdekelt felek követelményeit, valamint a más szervezetekkel fennálló interfészeket és függőségeket ISO/IEC 27001:2022.

Ennek a megfogalmazásnak 2026-ban nagyobb a jelentősége, mint a korábbi tanúsítási ciklusokban volt. A NIS2, a DORA, a GDPR, a felhőalapú kiszervezés, az ügyfélszerződések, a csoportszintű technológiai szolgáltatások és a menedzselt szolgáltatók nem mellékes megjegyzések. Ezek az IBIR határának bemenetei.

A NIS2 emeli az irányítási elvárásokat az alapvető és fontos szervezeteknél. Előírja, hogy a vezető testületek hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék azok végrehajtását és képzésben részesüljenek. A NIS2 Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket követel meg, ideértve a kockázatelemzést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos beszerzést és fejlesztést, az eredményesség értékelését, a kiberhigiéniát, a kriptográfiát, a HR-biztonságot, a hozzáférés-szabályozást, az eszközkezelést és adott esetben a többtényezős hitelesítést.

A DORA megváltoztatja a hatókörrel kapcsolatos párbeszédet a pénzügyi szervezeteknél. 2025. január 17-től alkalmazandó, és egységes követelményeket állapít meg az IKT-kockázatkezelésre, az IKT-vel kapcsolatos incidensjelentésre, a digitális működési reziliencia tesztelésére, az információmegosztásra és a harmadik fél által nyújtott IKT-szolgáltatások kockázatának kezelésére. A DORA Article 6 dokumentált IKT-kockázatkezelési keretrendszert ír elő. A DORA Article 8 megköveteli az IKT által támogatott üzleti funkciók, az információs vagyon és az IKT-eszközök azonosítását, osztályozását és dokumentálását, beleértve a függőségeket is. A DORA Article 28 a harmadik fél által nyújtott IKT-szolgáltatások kockázatának kezelését követeli meg.

A GDPR hozzáadja a személyes adatok tengelyét. Az automatizált vagy strukturált személyesadat-kezelésre vonatkozik, ideértve az EU-ban letelepedett szervezetek általi adatkezelést, valamint bizonyos nem EU-s adatkezelőket vagy adatfeldolgozókat, amelyek az Unióban tartózkodó személyeknek kínálnak árukat vagy szolgáltatásokat, illetve megfigyelik a viselkedésüket. A GDPR Article 30 adatkezelési tevékenységek nyilvántartását írja elő, az Article 32 az adatkezelés biztonságát követeli meg, az Article 33 pedig a személyesadat-sértés bejelentésére vonatkozó elvárásokat rögzíti.

Egy igazolható IBIR-hatókör ezért nem szervezeti egységek köré épül. Szabályozott szolgáltatások, kritikus vagy fontos funkciók, személyesadat-kezelés, támogató eszközök és harmadik félhez kapcsolódó függőségek köré kell felépíteni.

A hiba: az ISO 27001, a NIS2, a DORA és a GDPR külön programként kezelése

Sok szervezetnél visszatérő minta figyelhető meg:

• A biztonsági terület elkészíti az ISO 27001 hatókört.
• A jogi terület értékeli a NIS2 alkalmazhatóságát.
• A kockázatkezelési vagy megfelelési funkció kezeli a DORA kötelezettségeket.
• Az adatvédelem fenntartja a GDPR szerinti adatkezelési tevékenységek nyilvántartását.
• A beszerzés felel a beszállítói listáért.
• Az üzemeltetés felel az üzletmenet-folytonosságért és a katasztrófa-helyreállításért.

Mindegyik csapat végezhet érdemi munkát. A probléma az, hogy a szabályozott valóság mindegyik területet átmetszi.

Egy felhőben működő ügyfélidentitás-szolgáltatás egyszerre támogathat NIS2 szerinti szolgáltatásnyújtást, DORA által szabályozott ügyfélműveleteket és GDPR szerinti személyesadat-kezelést. Egy menedzselt detektálási szolgáltató lehet biztonsági beszállító, incidensreagálási függőség, naplóadatok adatfeldolgozója vagy al-adatfeldolgozója, valamint kulcsfontosságú bemenet a szabályozói bejelentési döntésekhez. Egy támogatási platform tekinthető „nem éles környezetnek”, miközben személyesadat-sértéssel kapcsolatos kommunikációt és ügyfélbizonyíték-kéréseket kezel.

Az IBIR a legalkalmasabb hely e kötelezettségek integrálására, mert az ISO 27001 egy fegyelmezett kérdést kényszerít ki: mi van a határon belül, mi van azon kívül, és miért?

A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ezt az ISMS Foundation & Leadership fázis 2. lépésében, a Stakeholder Needs and ISMS Scope témakörben kezeli:

„A kontextus megértését és az érdekelt felek követelményeinek azonosítását követően a 4.3 pont azt kéri, hogy határozza meg az IBIR határait és alkalmazhatóságát a hatókör rögzítéséhez. Az IBIR hatóköre kulcsfontosságú definíció, amely meghatározza, mi tartozik a biztonságirányítási program alá, és mi nem.”

A Zenith Blueprint egy olyan pontra is felhívja a figyelmet, amelyet sok hatókörnyilatkozat még mindig kihagy:

„Ha az IT-infrastruktúrát felhőszolgáltatóhoz szervezi ki, az nem zárja ki azt a hatókörből; ehelyett a kapcsolat kezelését és a felhőeszközöket a hatókör részeként kell kezelni.”

A kiszervezés a végrehajtást helyezi át. Az elszámoltathatóságot nem szünteti meg.

A négyhatáros modell az ISO 27001 hatókörhöz 2026-ban

A NIS2, DORA és GDPR által érintett szervezetek számára a Clarysec azt javasolja, hogy az ISO 27001 szerinti IBIR-hatókört négy összekapcsolt határ mentén határozzák meg.

Egy gyenge hatókörnyilatkozat csak annyit mond: „a SaaS platform”. Egy erősebb nyilatkozat meghatározza, mely üzleti szolgáltatások, rendszerek, környezetek, helyszínek, adatkezelési tevékenységek, munkatársi csoportok, beszállítói kapcsolatok és irányítási folyamatok tartoznak ide.

Egy jobban igazolható változat így hangozhat:

„Az IBIR kiterjed a vállalat EU-s SaaS fizetésianalitika-platformjához kapcsolódó információbiztonság irányítására, kockázatkezelésére, működtetésére és folyamatos fejlesztésére, beleértve az éles és nem éles felhőkörnyezeteket, az ügyfélidentitás-szolgáltatásokat, az adminisztrációs interfészeket, a támogatási műveleteket, a naplózási és monitorozási platformokat, az incidensreagálást, az üzletmenet-folytonosságot, a beszállítókezelést és a szolgáltatást támogató valamennyi személyesadat-kezelési tevékenységet. Az IBIR magában foglalja a szolgáltatásnyújtáshoz, rezilienciához, biztonsági monitorozáshoz vagy GDPR-rel kapcsolatos kommunikációhoz használt kiszervezett felhőtárhely, menedzselt detektálás és ügyféltámogatási eszközök kezelését.”

Ez a hatókör nem pusztán hosszabb. Jobban auditálható, mert összekapcsolja a szolgáltatásokat, eszközöket, adatkezelést és függőségeket.

Hogyan fordítják le a Clarysec szabályzatok a hatókört irányítási nyelvre?

A hatókör nem élhet önálló dokumentumban. Összhangban kell állnia az információbiztonsági szabályzattal, a jogi és szabályozói megfeleléssel, a kockázatkezeléssel, az adatvédelemmel, a beszállítói irányítással, az auditkritériumokkal és a folytonossági tervezéssel.

Az Enterprise Információbiztonsági szabályzat Információbiztonsági szabályzat megszünteti a kizárások körüli kétértelműséget:

„A hatókör bármely kizárását vagy korlátozását dokumentálni kell az IBIR hatókörnyilatkozatában, és a felső vezetés formális jóváhagyásával kell indokolni.”

Ez a záradék akkor fontos, amikor egy üzleti egység azt állítja, hogy az ügyféltámogatás a platformon kívül van, miközben a támogatási ügyintézők ügyfélazonosítókhoz férnek hozzá és személyesadat-sértéssel kapcsolatos kommunikációt kezelnek. Kizárás csak akkor lehetséges, ha azt dokumentálják, indokolják és jóváhagyják.

Az Enterprise Jogi és szabályozói megfelelési szabályzat Jogi és szabályozói megfelelési szabályzat működőképessé teszi a jogi megfeleltetést:

„Minden jogi és szabályozói 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 (ISMS).”

Ez a híd a jogi alkalmazhatóság és az Alkalmazhatósági Nyilatkozat között. A NIS2 Article 21 nem maradhat jogi feljegyzésben. A DORA harmadik fél IKT-kockázatával kapcsolatos kötelezettségek nem maradhatnak kizárólag beszerzési útmutatóban. A GDPR Article 30 és Article 32 szerinti kötelezettségek nem lehetnek kizárólag az adatvédelmi nyilvántartásban. Hozzárendelt felelősökre, kontrollokra és bizonyítékokra van szükségük.

Az Enterprise Kockázatkezelési szabályzat Kockázatkezelési szabályzat kiterjeszti a hatókört a harmadik felekre:

„Ez a szabályzat minden olyan szervezeti egységre, üzleti folyamatra, rendszerre, személyzetre és harmadik féllel fennálló kapcsolatra vonatkozik, amely részt vesz az információs vagyon kezelésében, fejlesztésében, tárolásában vagy irányításában.”

Ez a megfogalmazás összhangban van a NIS2 szerinti ellátási lánc biztonságával, a DORA szerinti harmadik fél IKT-kockázattal és a GDPR szerinti adatkezelői vagy adatfeldolgozói elszámoltathatósággal.

Az Enterprise Adatvédelmi és magánszféra-védelmi szabályzat Adatvédelmi és magánszféra-védelmi szabályzat az adatvédelmi hatókört az adatkezeléshez köti:

„Ez a szabályzat minden olyan szervezeti egységre, munkatársra és rendszerre vonatkozik, amely személyes információk (PII) kezelésében vesz részt, beleértve: ”

Az elv döntő jelentőségű. Ha egy rendszer PII-t kezel, nem lehet láthatatlan az IBIR számára pusztán azért, mert „csak támogatási célú”, „nem éles környezet” vagy „a marketing tulajdonában van”.

Az Enterprise Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat a hatókört a BIA eredményeihez köti:

„Ez a szabályzat minden olyan szervezeti egységre, információs rendszerre, üzleti folyamatra, személyzetre és harmadik fél szolgáltatásra vonatkozik, amelyet az üzleti hatáselemzés (BIA) eredményei alapján kritikusnak vagy alapvetőnek minősítettek.”

Ez a záradék természetesen illeszkedik a DORA szerinti kritikus vagy fontos funkciókhoz és a NIS2 szerinti szolgáltatás-folytonossághoz.

Kisebb szervezetek számára a Clarysec KKV-szabályzatai tömören fogalmaznak, miközben ugyanazt a logikát őrzik meg. A KKV Audit- és megfelelésfelügyeleti szabályzat Audit- és megfelelésfelügyeleti szabályzat - KKV az auditlefedettséget így határozza meg:

„Az információbiztonság-irányítási rendszer (ISMS) hatókörébe tartozó valamennyi kontroll és rendszer”

A KKV Adatvédelmi és magánszféra-védelmi szabályzat Adatvédelmi és magánszféra-védelmi szabályzat - KKV az adatvédelmi hatókört így határozza meg:

„Bármely rendszer, alkalmazás vagy helyszín, ahol személyes adatokat tárolnak vagy továbbítanak”

A KKV Kockázatkezelési szabályzat Kockázatkezelési szabályzat - KKV láthatóvá teszi a kiszervezett szolgáltatásokat:

„Minden belsőleg vagy harmadik feleken keresztül kezelt információ, szolgáltatás és eszköz”

Az ilyen rövid záradékok hatékonyak, mert megakadályozzák, hogy egy tanúsítási határ kizárja a szabályozott adatokat, felhőszolgáltatásokat vagy beszállító által kezelt eszközöket.

Az eszköznyilvántartásnál válik valósággá a hatókör

Egy hatókörnyilatkozat csak akkor hiteles, ha visszakövethető eszközökhöz, tulajdonosokhoz, beszállítókhoz, adatáramlásokhoz és bizonyítékokhoz.

A Zenith Blueprint a Risk Management fázis 9. lépésében, az Identifying Assets, Threats, and Vulnerabilities témakörben arra utasítja a szervezeteket, hogy sorolják fel az IBIR hatókörébe tartozó eszközöket, és rögzítsék a tulajdonost, a helyszínt és az osztályozást. Gyakorlati példát is ad:

„Ügyfél-adatbázis – tulajdonos: IT osztály – AWS-en üzemeltetve – személyes és pénzügyi adatokat tartalmaz (magas érzékenység).”

Ugyanez a lépés olyan hatókör-meghatározási emlékeztetőt is ad, amely közvetlenül releváns a NIS2 és a GDPR szempontjából:

„Gondoskodjon arról, hogy a személyes adatokat tartalmazó eszközök meg legyenek jelölve (GDPR relevancia miatt), és a kritikus szolgáltatási eszközök fel legyenek tüntetve (potenciális NIS2 alkalmazhatóság miatt, ha szabályozott ágazatban működik).”

A Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls az ISO/IEC 27002:2022 5.9 kontrollját, az információk és más kapcsolódó eszközök nyilvántartását alapvető, több megfelelési keretrendszert támogató kontrollként kezeli. Attribútumai megelőző kontrollként sorolják be, amely támogatja a bizalmasságot, sértetlenséget és rendelkezésre állást, illeszkedik az Identify kiberbiztonsági koncepcióhoz, az eszközkezelési operatív képességhez, valamint az irányítási, ökoszisztéma- és védelmi tartományokhoz.

A Zenith Controls egyértelműen magyarázza a GDPR és NIS2 relevanciát:

„Pontos és naprakész eszköznyilvántartás nélkül a szervezetek nem tudják felmérni vagy bevezetni a megfelelő védelmi intézkedéseket.”

A NIS2 esetében az eszköznyilvántartás támogatja az alapvető vagy fontos szolgáltatásokat alátámasztó kritikus rendszerek és komponensek azonosítását. A DORA esetében a DORA Article 8 az IKT-eszközök és az információs vagyon azonosítását az operatív reziliencia központi elemévé teszi. A GDPR esetében az eszköznyilvántartás támogatja az adatáramlások feltérképezését, a RoPA minőségét és a személyesadat-sértés kezelését.

A támogató ISO szabványok ugyanezt a logikát erősítik. Az ISO/IEC 27005:2024 megerősíti az eszközazonosítást az információbiztonsági kockázatértékelésben. Az ISO 22301:2019 támogatja az üzletmenet-folytonossághoz szükséges erőforrások azonosítását. Az ISO/IEC 19770-1:2017 támogatja az IT-eszközkezelési érettséget. Az ISO/IEC 27017:2015 és az ISO/IEC 27018:2019 támogatja a felhőspecifikus kontrollokat és a PII védelmét nyilvános felhőkben. Az ISO/IEC 27701:2019 kiterjeszti az adatvédelmi információkezelést. Az ISO/IEC 29100:2011 hozzájárul olyan adatvédelmi alapelvekhez, mint az átláthatóság, az adattakarékosság és a biztonsági védelmi intézkedések.

Gyakorlati hatókör-meghatározási gyakorlat SaaS- és fintech csapatoknak

Egy szabályozott szolgáltatással kezdjen, ne az egész vállalattal. Például: „EU-s fizetésianalitika-SaaS pénzügyi intézmények számára.”

Ezután készítsen szolgáltatás–eszköz–adatkezelés térképet.

Egy részletesebb eszközminta így nézhet ki.

Ezt követően használja a Zenith Blueprint 13. lépését: Risk Treatment Planning and Statement of Applicability. Az útmutató arra utasítja a felhasználókat, hogy a SoA-t olyan sablon alapján építsék fel, amely felsorolja az Annex A összes kontrollját, és az alkalmazhatóságról a kockázatkezelés, a jogi vagy szerződéses követelmények, a hatóköri relevancia és a szervezeti kontextus alapján döntsenek. Így fogalmaz:

„A SoA munkalap minden egyes kontrolljánál (soránál) döntse el, hogy alkalmazható-e az Ön IBIR-jére.”

A fenti példában a SoA-nak figyelembe kell vennie a beszállítói biztonság, a felhőszolgáltatások, az incidenskezelés, a folytonosság, a jogi és szabályozói követelmények, az adatvédelem, a sérülékenységkezelés, a biztonsági mentések, a naplózás, a monitorozás, a kriptográfia, a biztonságos fejlesztés, a biztonsági tesztelés és a változáskezelés kontrolljait.

Gyakorlati munkafolyamat:

1. Hozzon létre egy „IBIR hatókör-feltérképezés” fület a kockázati nyilvántartásban és a SoA Builderben.
2. Adjon hozzá egy sort minden szabályozott szolgáltatáshoz vagy termékvonalhoz.
3. Kapcsolja össze az egyes szolgáltatásokat eszközökkel, adattípusokkal, beszállítókkal, helyszínekkel és üzleti tulajdonosokkal.
4. Jelölje a NIS2 relevanciát, a DORA relevanciát és a GDPR szerinti adatkezelési relevanciát.
5. Adjon hozzá kockázati forgatókönyveket szolgáltatáselérhetetlenségre, személyesadat-sértésre, beszállítói hibára, felhőhibás konfigurációra, kritikus sérülékenységre és incidensjelentési hibára.
6. Válassza ki a SoA-kontrollokat e kockázatok és kötelezettségek alapján.
7. Dokumentálja a kizárásokat, a kompenzáló kontrollokat és a kockázatelfogadást.
8. Szerezze be a felső vezetés jóváhagyását a végleges határokra és kizárásokra.
9. Vezesse át a végleges határt a belső auditba, a vezetőségi felülvizsgálatba és a beszállítói felügyeletbe.

Az eredmény nem csupán jobb hatókörnyilatkozat. Igazolható lánc a szabályozott szolgáltatástól az eszközig, beszállítóig, adatig, kontrollig, felelősig és bizonyítékig.

Keresztmegfelelési feltérképezés: egy hatókör, több kötelezettség

A jól meghatározott ISO 27001 szerinti IBIR olyan működési réteggé válik, amelyben a NIS2, a DORA, a GDPR, a NIST CSF és a COBIT elvárásai összehangolhatók.

Az ISO/IEC 27002:2022 5.31 kontrollja, a jogi, törvényi, szabályozói és szerződéses követelmények esetében a Zenith Controls a megfelelési kötelezettségeket az adatvédelemhez, a PII védelméhez, a nyilvántartások megőrzéséhez, a független felülvizsgálathoz és a belső szabályzatoknak való megfeleléshez kapcsolja. Természetesen illeszkedik a GDPR elszámoltathatósághoz, a NIS2 szerinti ellátási lánc megfelelőségéhez, a DORA szerinti IKT-kockázatkezeléshez és megfeleléshez, a NIST CSF irányításhoz, valamint a COBIT 2019 külső megfelelés-monitorozásához.

Az ISO/IEC 27002:2022 5.34 kontrollja, a PII adatvédelme és védelme esetében a Zenith Controls az adatvédelmet az eszköznyilvántartáshoz, felhőszolgáltatásokhoz, osztályozáshoz, információátadáshoz, hozzáférés-szabályozáshoz, identitáskezeléshez és projektváltozás-felülvizsgálatokhoz kapcsolja. GDPR-megfeleltetése lefedi az adatkezelés biztonságát és a beépített adatvédelmet. DORA-megfeleltetése támogatja az adatok sértetlenségét, biztonságát és bizalmasságát, beleértve az IKT-szolgáltatásokban kezelt személyes adatokat is.

Az elv egyszerű: ne hozzon létre négy szétkapcsolt megfelelési programot. Hozzon létre egy hatókörrel rendelkező IBIR-t, amely meg tudja magyarázni, hogyan teljesülnek, hogyan igazolhatók és hogyan auditálhatók a kötelezettségek.

Incidensjelentési hatókör: ahol a határok hatnak a szabályozói órákra

A hibás hatókör incidensek során válik igazán fájdalmassá.

A NIS2 Article 23 szakaszos jelentős incidensjelentést ír elő, ideértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést, a kérésre benyújtandó közbenső jelentéseket és az egy hónapon belüli zárójelentést. Szükség lehet az érintett címzettek tájékoztatására is.

A DORA előírja, hogy a pénzügyi szervezetek észleljék, kezeljék, osztályozzák és jelentsék a jelentős IKT-vel kapcsolatos incidenseket olyan szempontok alapján, mint az érintett ügyfelek vagy szerződő felek, az időtartam, a kiesési idő, a földrajzi kiterjedés, az adatvesztés, az érintett szolgáltatások kritikussága és a gazdasági hatás. Az ügyfeleket indokolatlan késedelem nélkül tájékoztatni kell, ha egy jelentős IKT-incidens érinti pénzügyi érdekeiket.

A GDPR szerinti személyesadat-sértés bejelentése attól függ, hogy a sértés a személyes adatok véletlen vagy jogellenes megsemmisítéséhez, elvesztéséhez, megváltoztatásához, jogosulatlan közléséhez vagy az azokhoz való jogosulatlan hozzáféréshez vezet-e.

Ha a támogatási platform, a naplókörnyezet, az identitásszolgáltatás, az ügyfélértesítési csatorna vagy a menedzselt detektálási szolgáltató az IBIR hatókörén kívül marad, az incidenskezelő csapatok nem feltétlenül tudják, hogy egy esemény NIS2, DORA, GDPR, ügyfélszerződés szerinti jelentéstételt vagy mindezeket kiváltja-e. Ez a bizonytalanság felemészti a jelentéstételi határidőt.

Egy érett hatókör tartalmazza az incidens szempontjából releváns függőségeket: detektálóeszközöket, naplótárakat, forenzikus adattárakat, ügyfélkommunikációs csatornákat, támogatási eszközöket, biztonsági mentési környezeteket, incidenshidakat és a triázsban vagy helyreállításban részt vevő beszállítókat.

Hogyan tesztelik az auditorok és felügyeletek az IBIR hatókörét?

Az erős hatókör túléli a mintavételt. A gyenge hatókör összeomlik, amikor az auditorok összevetik a dokumentumokat a valósággal.

A Zenith Controls hasznos auditelvárásokat ad az ISO/IEC 27002:2022 5.9 kontrolljához. Az ISO/IEC 19011 jellegű auditorok már korán kérik a nyilvántartást más értékelések hatókörének meghatározásához, valamint a fizikai, szoftveres és felhőeszközök szúrópróbaszerű ellenőrzéséhez. Az ISO/IEC 27007 jellegű auditorok azt kérdezik, hogyan és mikor frissítik a nyilvántartást, és kapcsolatot keresnek a beszerzéssel, a változáskezeléssel és az üzemen kívül helyezéssel. A NIST SP 800-53A jellegű auditorok ellenőrzik, hogy a nyilvántartási adatok tartalmazzák-e az eszköztípust, a tulajdonost, a helyszínt, adott esetben a hálózati címet és az állapotot, valamint hogy a felhő-, virtuális és mobileszközök is szerepelnek-e.

Az 5.31 kontroll esetében a Zenith Controls megjegyzi, hogy a tanúsító auditorok megfelelési nyilvántartást vagy jogszabály- és szerződéslistát várnak el, amelyre a SoA és a kockázatkezelési tervek hivatkoznak. A COBIT auditorok megfelelési felelősöket, értékeléseket és felsővezetői jelentéstételt keresnek. Az ISACA ITAF auditorok bizonyítékmintákat vesznek annak megerősítésére, hogy a szervezet nemcsak ismeri a kötelezettségeit, hanem aktívan biztosítja is azok teljesülését.

Az 5.34 kontroll esetében az auditorok adatvédelmi szabályzatokat, adatnyilvántartásokat, DPIA-kat, képzési naplókat, titkosítási bizonyítékokat, hozzáférés-szabályozást, DSAR-mintákat, beépített adatvédelmi bizonyítékokat és PII-t érintő incidensnyilvántartásokat tekintenek át. Gyorsan megkérdőjelezik azt a hatókörnyilatkozatot, amely kizár egy személyes adatokat kezelő rendszert.

Az igazgatósági kérdés: mi nem zárható ki?

A felső vezetés gyakran megkérdezi, hogy egy üzleti egység, helyszín, beszállító vagy rendszer maradhat-e az IBIR hatókörén kívül. Néha a válasz igen. De nem akkor, ha a kizárás megakadályozza a szervezetet jogi, szabályozói, szerződéses vagy szolgáltatásbiztonsági kötelezettségei teljesítésében.

Bármely határkorlátozás jóváhagyása előtt alkalmazza ezt a kizárási tesztet:

• Támogatja-e az egység, rendszer vagy beszállító a NIS2 által szabályozott szolgáltatást?
• Támogat-e DORA szerinti kritikus vagy fontos funkciót a szervezet vagy annak szabályozott ügyfelei számára?
• Gyűjt, tárol, továbbít, naplóz, támogat vagy töröl-e személyes adatokat?
• Nyújt-e biztonsági monitorozást, identitáskezelést, biztonsági mentést, incidensreagálást vagy helyreállítást hatókörbe tartozó szolgáltatáshoz?
• Biztosít-e az incidensosztályozáshoz vagy szabályozói bejelentéshez szükséges bizonyítékot?
• Előírja-e ügyfélszerződés, hogy az IBIR lefedje?
• Kompromittálódása hatással lenne-e a megadott hatókörön belüli bizalmasságra, sértetlenségre, rendelkezésre állásra, jogi megfelelésre vagy szolgáltatás-folytonosságra?

Ha a válasz igen, a kizáráshoz erős bizonyíték, kompenzáló irányítás, kockázatelfogadás és a felső vezetés formális jóváhagyása szükséges. Sok esetben nem szabad kizárni.

Egy korszerű ISO 27001 szerinti IBIR-hatókörnek tartalmaznia kell:

1. A lefedett üzleti szolgáltatásokat és termékvonalakat.
2. A lefedett jogi entitásokat, szervezeti egységeket és helyszíneket.
3. A kötelezettségeket meghatározó ügyfélszegmenseket és joghatóságokat.
4. A kritikus vagy fontos funkciókat és a BIA-alapú alapvető szolgáltatásokat.
5. Az információs vagyont, IKT-eszközöket és felhőkörnyezeteket.
6. A személyesadat-kezelési tevékenységeket és PII-adattárakat.
7. A fejlesztési, tesztelési, támogatási, monitorozási és incidensfolyamatokat.
8. A hatókörbe tartozó szolgáltatásokat támogató beszállítókat és kiszervezett szolgáltatásokat.
9. A csoportvállalatokkal vagy külső szolgáltatókkal fennálló interfészeket és függőségeket.
10. Az egyértelmű kizárásokat indoklással, kockázatelfogadással és felsővezetői jóváhagyással.

Így válik az ISO 27001 hatóköre igazgatósági szintű irányítási állásfoglalássá, nem pedig tanúsítási rövidítéssé.

Tegye auditra felkészültté az IBIR hatókörét, mielőtt az auditor határozza meg Ön helyett

A legrosszabb időpont egy hatóköri probléma felismerésére a tanúsítás, a felügyeleti felülvizsgálat, az ügyféloldali átvilágítás vagy egy éles incidens.

Egy szűk tanúsítvány kielégíthet egy beszerzési jelölőnégyzetet, de nem állja ki a komoly vizsgálatot, ha kizárja azokat a szolgáltatásokat, IKT-funkciókat, beszállítókat és személyesadat-kezelési tevékenységeket, amelyek szabályozási kitettséget teremtenek. 2026-ban azok a szervezetek fognak magabiztosan átmenni az auditokon, amelyek egy koherens térképet tudnak bemutatni a szabályozott szolgáltatástól az eszközön, beszállítón, személyes adaton, kontrollon, felelősen és bizonyítékon át.

Kezdje három konkrét lépéssel:

1. Használja a Zenith Blueprint Zenith Blueprint ISMS Foundation & Leadership fázisának 2. lépését, és dolgozza át az IBIR hatókörét szolgáltatások, funkciók, adatkezelés és függőségek köré.
2. Használja a Zenith Controls Zenith Controls útmutatót az eszköznyilvántartás, a jogi kötelezettségek és a PII-védelem feltérképezésére az ISO 27001, NIS2, DORA, GDPR, NIST és COBIT 2019 audit elvárásai mentén.
3. Hangolja össze a szabályzati hatókört a Clarysec Információbiztonsági szabályzat Információbiztonsági szabályzat, Jogi és szabályozói megfelelési szabályzat Jogi és szabályozói megfelelési szabályzat, Kockázatkezelési szabályzat Kockázatkezelési szabályzat, Adatvédelmi és magánszféra-védelmi szabályzat Adatvédelmi és magánszféra-védelmi szabályzat és Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat Üzletmenet-folytonossági és katasztrófa-helyreállítási szabályzat alapján.

Ha a jelenlegi IBIR-hatókör még mindig szervezeti egység címkéjeként olvasható, építse újra megfelelési határként. Töltse le a Clarysec eszközkészleteit, térképezzen fel egy szabályozott szolgáltatást teljes egészében, és alakítsa az ISO 27001 hatókörét auditra való felkészültséget biztosító bizonyítékká a NIS2, a DORA és a GDPR számára.