DORA IKT-kilépési stratégiák ISO 27001 kontrollokkal
Hétfőn 07:42-kor egy fintech üzemeltetési vezető megkapja azt az üzenetet, amelyet senki sem szeretne olvasni: a vállalat felhőalapú tranzakciómonitorozási szolgáltatójánál súlyos regionális kiesés történt. 08:15-kor a kockázatkezelési vezető (CRO) már azt kérdezi, hogy az érintett szolgáltatás kritikus vagy fontos funkciót támogat-e. 08:40-kor a jogi terület azt szeretné tudni, hogy a szerződés biztosít-e a vállalat számára átállási támogatást, adatexportot, törlést és auditálási jogokat. 09:05-kor az információbiztonsági vezető (CISO) már olyan bizonyítékot keres, amely igazolja, hogy a kilépési tervet nemcsak elkészítették, hanem tesztelték is.
Egy másik pénzügyi szolgáltatónál Sarah, egy gyorsan növekvő fintech platform CISO-ja, megnyit egy DORA megfelelésértékeléshez kapcsolódó előzetes auditori adatkérést. A kérdések ismerősek egészen addig, amíg el nem jut a kritikus vagy fontos funkciókat támogató, harmadik fél által nyújtott IKT-szolgáltatásokról szóló részhez. Az auditorok nem azt kérdezik, van-e a vállalatnak beszállítói szabályzata. Dokumentált, tesztelt és életképes kilépési stratégiákat kérnek.
Sarah gondolatai először a platformot futtató alapvető felhőszolgáltatóhoz, majd ahhoz a menedzselt biztonsági szolgáltatóhoz (MSSP) fordulnak, amely éjjel-nappal monitorozza a fenyegetéseket. Mi történik, ha a felhőszolgáltatót geopolitikai zavar éri? Mi történik, ha az MSSP-t egy versenytárs felvásárolja? Mi történik, ha egy kritikus SaaS-szolgáltató fizetésképtelenné válik, megszünteti a szolgáltatást, vagy egy jelentős incidens után elveszíti az ügyfelek bizalmát?
Sok vállalatnál a kellemetlen válasz ugyanaz. Van beszállítói kockázatértékelés, üzletmenet-folytonossági terv, szerződésmappa, felhőleltár és talán biztonsági mentési jelentés is. Nincs azonban egyetlen auditkész DORA IKT-kilépési stratégia, amely összekapcsolná az üzleti kritikusságot, a szerződéses jogokat, a műszaki hordozhatóságot, a folytonossági terveket, a biztonsági mentési bizonyítékokat, az adatvédelmi kötelezettségeket és a vezetői jóváhagyást.
A DORA megváltoztatja a beszállítókezelés súlypontját. Az (EU) 2022/2554 rendelet alapján a pénzügyi szervezeteknek a harmadik fél által jelentett IKT-kockázatot az IKT-kockázatkezelési keretrendszer részeként kell kezelniük. Továbbra is teljes mértékben felelősek maradnak a megfelelésért, nyilvántartást vezetnek az IKT-szolgáltatási szerződésekről, megkülönböztetik a kritikus vagy fontos funkciókat támogató IKT-megállapodásokat, értékelik a koncentrációs és alvállalkozói kockázatokat, és kilépési stratégiákat tartanak fenn a kritikus IKT-függőségekre. A DORA 2025. január 17-től alkalmazandó, és egységes uniós követelményeket állapít meg az IKT-kockázatkezelésre, az incidensbejelentésre, a rezilienciatesztelésre, az információmegosztásra és a harmadik fél által jelentett IKT-kockázat kezelésére a pénzügyi szervezetek széles körében.
A DORA szerinti kilépési stratégia nem egy bekezdés a beszállítói szerződésben. Kontrollrendszer. Irányítani kell, kockázatértékelésnek kell alávetni, műszakilag megvalósíthatónak, szerződésesen érvényesíthetőnek, teszteltnek, bizonyítékokkal alátámasztottnak és folyamatosan fejlesztettnek kell lennie.
A Clarysec megközelítése a Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, a vállalati szabályzatsablonok és a Zenith Controls: The Cross-Compliance Guide Zenith Controls kombinációjával a hétfő reggeli kérdést előre előkészített válasszá alakítja.
Miért buknak el a DORA kilépési stratégiák a valódi auditokon
A legtöbb DORA IKT-kilépési stratégia már szerkezeti szinten hibás, mielőtt a műszaki kérdésekig eljutna. A szervezetnek van beszállítói kapcsolattartója, de nincs elszámoltatható kockázattulajdonosa. Vannak biztonsági mentési feladatok, de nincs helyreállítási bizonyíték. Van beszállítói átvilágítási kérdőív, de nincs dokumentált döntés arról, hogy a szolgáltató kritikus vagy fontos funkciót támogat-e. Van szerződéses megszüntetési rendelkezés, de nincs az üzletmenet-folytonossági tervhez igazított átállási időszak.
A DORA ezeket az elemeket egymáshoz rendeli. Article 28 meghatározza a harmadik fél által jelentett IKT-kockázat kezelésének általános elveit, ideértve az IKT-szolgáltatást nyújtó harmadik felekkel kapcsolatos kockázat teljes életcikluson át történő kezelését és a megfelelő kilépési stratégiák fenntartását. Article 30 részletes szerződéses követelményeket határoz meg a kritikus vagy fontos funkciókat támogató IKT-szolgáltatásokra, beleértve a szolgáltatásleírásokat, az adatkezelési helyszíneket, a biztonsági védelmi intézkedéseket, a hozzáférési és auditálási jogokat, az incidenskezelési támogatást, az illetékes hatóságokkal való együttműködést és a megszüntetési jogokat.
A rendelet arányossági elven is alapul. Articles 4 and 16 lehetővé teszi bizonyos kisebb vagy mentesített szervezetek számára, hogy egyszerűsített IKT-kockázatkezelési keretrendszert alkalmazzanak. Az egyszerűsített azonban nem jelent dokumentálatlant. A kisebb pénzügyi szervezeteknek továbbra is dokumentált IKT-kockázatkezelésre, folyamatos monitorozásra, reziliens rendszerekre, az IKT-incidensek gyors azonosítására, a kulcsfontosságú IKT-függőségek azonosítására, biztonsági mentésre és helyreállításra, üzletmenet-folytonosságra, reagálásra és helyreállításra, tesztelésre, a levont tanulságok kezelésére és képzésre van szükségük.
Egy kis fintech nem mondhatja azt, hogy „túl kicsik vagyunk a kilépéstervezéshez”. Azt mondhatja: „A DORA kilépési stratégiánk a méretünkhöz, kockázati profilunkhoz és szolgáltatási komplexitásunkhoz igazodik.” A különbség a bizonyíték.
Azon szervezetek esetében, amelyek a NIS2 nemzeti hatálya alá is tartoznak, a DORA a pénzügyi szektorban átfedő kiberbiztonsági kötelezettségekre vonatkozó ágazatspecifikus uniós jogi aktusként működik. A NIS2 továbbra is fontos a tágabb ökoszisztémában, különösen a menedzselt szolgáltatók, a menedzselt biztonsági szolgáltatók, a felhőszolgáltatók, az adatközpontok és a digitális infrastruktúra szereplői számára. A NIS2 Article 21 ugyanazokat a témákat erősíti: kockázatelemzés, incidenskezelés, üzletmenet-folytonosság, ellátásilánc-biztonság, biztonságos beszerzés, hatékonyságértékelés, képzés, kriptográfia, hozzáférés-szabályozás, eszközkezelés és hitelesítés.
A felügyeletek, ügyfelek, auditorok és igazgatóságok eltérően tehetik fel a kérdést, de a lényeg ugyanaz: ki tud-e lépni a szervezet egy kritikus IKT-szolgáltatóból anélkül, hogy elveszítené az ellenőrzést a szolgáltatás-folytonosság, az adatok, a bizonyítékok vagy az ügyfélhatás felett?
A kilépési stratégia legyen az IBIR része
Az ISO/IEC 27001:2022 biztosítja a DORA kilépéstervezés irányítási rendszerbeli gerincét.
A 4.1–4.4 pontok előírják, hogy a szervezet határozza meg a kontextusát, az érdekelt feleket, a jogi, szabályozási és szerződéses követelményeket, az IBIR alkalmazási területét, interfészeit, függőségeit és folyamatait. Itt azonosítja egy pénzügyi szervezet a DORA-t, az ügyfélvállalásokat, a kiszervezési elvárásokat, a felhőfüggőségeket, az adatvédelmi kötelezettségeket, az alvállalkozókat és az IBIR határain belüli IKT-szolgáltatásokat.
Az 5.1–5.3 pontok vezetői elkötelezettséget, szabályzatot, erőforrásokat, szerepkör-hozzárendelést és elszámoltathatóságot követelnek meg. Ez összhangban áll a DORA irányítási modelljével, amelyben az irányító testület meghatározza, jóváhagyja, felügyeli az IKT-kockázatkezelést, és felelős marad érte, beleértve az IKT-üzletmenet-folytonosságot, a reagálási és helyreállítási terveket, az IKT auditterveket, a költségvetéseket, a rezilienciastratégiát és a harmadik fél által jelentett IKT-kockázatra vonatkozó szabályzatot.
A 6.1.1–6.1.3 pontok a kilépéstervezést kockázatkezeléssé alakítják. A szervezet meghatározza a kockázati kritériumokat, ismételhető kockázatértékeléseket végez, azonosítja a bizalmasságot, sértetlenséget és rendelkezésre állást érintő kockázatokat, kijelöli a kockázattulajdonosokat, értékeli a következményeket és a valószínűséget, kiválasztja a kezelési lehetőségeket, összeveti a kontrollokat az Annex A-val, elkészíti az alkalmazhatósági nyilatkozatot, előkészíti a kockázatkezelési tervet, valamint megszerzi a kockázattulajdonos jóváhagyását és a maradványkockázat elfogadását.
A 8.1 pont ezt követően működéstervezést és működésfelügyeletet ír elő. A szervezetnek meg kell terveznie, végre kell hajtania és kontroll alatt kell tartania az IBIR-folyamatokat, fenn kell tartania azokat a dokumentált információkat, amelyek igazolják, hogy a folyamatokat a tervezettek szerint hajtották végre, kezelnie kell a változásokat, és kontrollálnia kell az IBIR szempontjából releváns, külső fél által biztosított folyamatokat, termékeket vagy szolgáltatásokat.
Az ISO/IEC 27005:2022 megerősíti ezt a megközelítést. A 6.2 pont azt javasolja, hogy a szervezetek azonosítsák az érdekelt felek követelményeit, beleértve az ISO/IEC 27001:2022 Annex A kontrollokat, az ágazatspecifikus szabványokat, a nemzeti és nemzetközi jogszabályokat, a belső szabályokat, a szerződéses követelményeket és a korábbi kockázatkezelésből származó meglévő kontrollokat. A 6.4.1–6.4.3 pontok kifejtik, hogy a kockázati kritériumoknak figyelembe kell venniük a jogi és szabályozási szempontokat, a beszállítói kapcsolatokat, az adatvédelmet, a működési hatásokat, a szerződésszegéseket, a harmadik felek tevékenységét és a reputációs következményeket. A 8.2–8.6 pontok olyan kontrollkönyvtárat és kezelési tervet támogatnak, amely az ISO/IEC 27001:2022 Annex A mellett a DORA, a NIS2, a GDPR, az ügyfélvállalások és a belső szabályzatok követelményeit is egyesítheti.
A működési modell egyszerű: egy követelményjegyzék, egy beszállítói kockázati nyilvántartás, egy alkalmazhatósági nyilatkozat, egy kockázatkezelési terv és egy bizonyítékcsomag minden kritikus kilépési forgatókönyvhöz.
Az ISO/IEC 27001:2022 kontrollok, amelyekre a DORA kilépéstervezés épül
A DORA kilépési stratégiák akkor válnak auditálhatóvá, ha a beszállítói irányítást, a felhőbeli hordozhatóságot, a folytonossági tervezést és a biztonsági mentési bizonyítékokat egy összefüggő kontrolláncként kezelik.
A Clarysec Zenith Controls az ISO/IEC 27001:2022 Annex A kontrollokat kontrollattribútumokhoz, auditbizonyítékokhoz és keresztmegfelelési elvárásokhoz rendeli. Nem külön kontrollkeretrendszer. A Clarysec keresztmegfelelési útmutatója annak megértéséhez, hogy az ISO/IEC 27001:2022 kontrollok hogyan támogatják az audit-, szabályozási és működési eredményeket.
| ISO/IEC 27001:2022 Annex A kontroll | Szerepe a kilépési stratégiában | Támogatott DORA bizonyíték | Auditori fókusz |
|---|---|---|---|
| A.5.19 Információbiztonság a beszállítói kapcsolatokban | Létrehozza a beszállítói kockázatkezelési folyamatot | Beszállítói besorolás, függőségi felelősség, kockázatértékelés | Következetesen kezelik-e a beszállítói kockázatot? |
| A.5.20 Információbiztonság kezelése a beszállítói megállapodásokban | A kilépési elvárásokat érvényesíthető szerződéses feltételekké alakítja | Megszüntetési jogok, auditálási jog, átállási támogatás, incidensek támogatása, adatok visszaadása és törlése | A szerződés ténylegesen támogatja-e a kilépési tervet? |
| A.5.21 Információbiztonság kezelése az IKT-ellátási láncban | Kiterjeszti az ellenőrzést az alvállalkozókra és a downstream függőségekre | Alvállalkozói átláthatóság, lánckockázat, koncentrációs értékelés | Érti-e a vállalat a rejtett függőségeket? |
| A.5.22 Beszállítói szolgáltatások monitorozása, felülvizsgálata és változáskezelése | Naprakészen tartja a beszállítói kockázatot a szolgáltatásváltozások során | Felülvizsgálati feljegyzések, szolgáltatásváltozási értékelések, helyesbítő intézkedések nyomon követése | Folyamatos-e a beszállítói felügyelet? |
| A.5.23 Információbiztonság felhőszolgáltatások használata esetén | Kontrollálja a felhőszolgáltatások bevezetését, használatát, kezelését, hordozhatóságát és kivezetését | Adatexport, törlés, migrációs támogatás, beszállítói függőségi bizonyíték | Vissza tudja-e szerezni és biztonságosan el tudja-e távolítani a vállalat az adatokat? |
| A.5.30 IKT-felkészültség az üzletmenet-folytonosságra | Teszteli, hogy a kritikus IKT-szolgáltatások helyreállíthatók vagy kiválthatók-e az üzleti tűréshatárokon belül | Folytonossági tervek, helyreállítási célok, tartalék megoldások, tesztelt kerülőeljárások | Műszakilag megvalósítható-e a kilépés zavart működési helyzetben? |
| A.8.13 Információk biztonsági mentése | Helyreállítható adatokat biztosít kilépési vagy hibaforgatókönyvekhez | Biztonsági mentési ütemezések, helyreállítási teszteredmények, sértetlenségi ellenőrzések | Helyreállíthatók-e az adatok az RTO és RPO keretein belül? |
Egy DORA IKT-kilépési stratégia esetében az auditnyomnak igazolnia kell, hogy:
- A beszállítót besorolták és üzleti folyamatokhoz kapcsolták.
- A szolgáltatást értékelték abból a szempontból, hogy kritikus vagy fontos funkciót támogat-e.
- A kilépési kockázatot elszámoltatható kockázattulajdonossal rögzítették.
- A szerződéses záradékok támogatják az átállást, a hozzáférést, az auditot, az adatok visszaadását, az adatok törlését, az együttműködést és a folytonosságot.
- A felhőbeli hordozhatóságot és interoperabilitást ellenőrizték.
- A biztonsági mentések és helyreállítási tesztek igazolják a helyreállíthatóságot.
- Az ideiglenes helyettesítést vagy alternatív feldolgozást dokumentálták.
- A kilépési teszteredményeket felülvizsgálták, helyesbítették, és jelentették a vezetésnek.
A szerződéses nyelvezet az első folytonossági kontroll
A szerződésnek az első folytonossági kontrollnak kell lennie, nem pedig a folytonosság akadályának. Ha a szolgáltató gyorsan megszüntetheti a szolgáltatást, késleltetheti az exportokat, korlátozhatja a naplókhoz való hozzáférést, meghatározatlan átállási díjakat számíthat fel, vagy megtagadhatja a migrációs támogatást, a kilépési stratégia sérülékeny.
A Zenith Blueprint Kontrollok működésben fázisának 23. lépésében az 5.20 kontroll elmagyarázza, hogy a beszállítói megállapodásoknak tartalmazniuk kell azokat a gyakorlati biztonsági követelményeket, amelyek lehetővé teszik a kilépést:
A beszállítói megállapodásokban jellemzően kezelt fő területek a következők:
✓ Titoktartási kötelezettségek, beleértve a hatályt, az időtartamot és a harmadik felek felé történő közzététel korlátozásait;
✓ Hozzáférés-szabályozási felelősségek, például ki férhet hozzá az adataihoz, hogyan kezelik a hitelesítő adatokat, és milyen monitorozás működik;
✓ Technikai és szervezési intézkedések az adatvédelemre, titkosításra, biztonságos átvitelre, biztonsági mentésre és rendelkezésre állási vállalásokra;
✓ Incidensbejelentési határidők és protokollok, gyakran meghatározott időkeretekkel;
✓ Auditálási jog, beleértve a gyakoriságot, a hatályt és a releváns bizonyítékokhoz való hozzáférést;
✓ Alvállalkozói kontrollok, amelyek előírják a beszállítónak, hogy azonos biztonsági kötelezettségeket adjon tovább a downstream partnereinek;
✓ Szerződésvégi rendelkezések, például adatok visszaadása vagy megsemmisítése, eszközvisszavétel és fiókdeaktiválás.
Ez a lista hidat képez a DORA Article 30 szerződéses elvárásai és az ISO/IEC 27001:2022 Annex A A.5.20 kontrollja között.
A Clarysec vállalati szabályzati nyelvezete ugyanezt működési szinten is megfogalmazza. A Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat „Végrehajtási követelmények” szakaszának 6.4.3 pontja kimondja:
Műszaki tartalék megoldások: biztosítani kell az adathordozhatóságot és az interoperabilitást a szolgáltatás átállásának támogatására, ha ez szükséges (pl. rendszeres biztonsági mentések szabványos formátumokban egy SaaS-szolgáltatótól a migráció lehetővé tétele érdekében).
Ugyanezen szabályzat 6.8.2 pontja előírja:
Átállási támogatáshoz való jogot (kilépést támogató záradék) kell biztosítani, ha szolgáltatóváltás szükséges, beleértve a szolgáltatás folytatását egy meghatározott átállási időszak alatt.
Ez a záradék gyakran eldönti, hogy egy kilépési stratégia megfelel-e az auditon. A kilépést szakadékszerű eseményből irányított átállássá alakítja.
Kisebb szervezetek esetében a Third-Party and Supplier Security Policy-sme Harmadik fél és beszállítói biztonsági szabályzat – KKV „Irányítási követelmények” szakaszának 5.3.6 pontja előírja:
Megszüntetési feltételek, beleértve az adatok biztonságos visszaadását vagy megsemmisítését
Vállalati környezetekben a Harmadik fél és beszállítói biztonsági szabályzat Harmadik fél és beszállítói biztonsági szabályzat „A szabályzat végrehajtásának követelményei” szakaszának 6.5.1.2 pontja előírja:
A szervezet tulajdonában álló valamennyi információ visszaadása vagy tanúsított megsemmisítése
Ezeknek a szabályzati követelményeknek közvetlenül visszakövethetőnek kell lenniük a szerződéses záradékokhoz, beszállítói eljárásokhoz, kilépési runbookokhoz és auditbizonyítékokhoz.
Felhőből való kilépés: tesztelje a hordozhatóságot, mielőtt szüksége lenne rá
A felhőszolgáltatásoknál válnak gyakran homályossá a DORA kilépési stratégiák. A vállalat feltételezi, hogy exportálni tudja az adatokat, de senki sem tesztelte a formátumot. Feltételezi, hogy a törlés megtörténik, de a szolgáltató megőrzési modellje biztonsági mentéseket és replikált tárolást is tartalmaz. Feltételezi, hogy egy alternatív szolgáltató képes fogadni az adatokat, de a sémák, identitásintegrációk, titkosítási kulcsok, titkok, naplók, alkalmazásprogramozási interfészek és sebességkorlátozások miatt a migráció lassabb lehet, mint amit a hatástűrés megenged.
Az ISO/IEC 27001:2022 Annex A A.5.23 kontrollja ezt az életciklus-problémát kezeli azzal, hogy információbiztonsági kontrollokat ír elő a felhőszolgáltatások beszerzésére, használatára, kezelésére és kivezetésére.
A Clarysec Felhőszolgáltatások használatára vonatkozó szabályzat-sme Felhőszolgáltatások használatára vonatkozó szabályzat – KKV „A szabályzat végrehajtásának követelményei” szakaszának 6.3.4 pontja előírja:
Az adatexport-képességet a beléptetés előtt meg kell erősíteni (pl. a beszállítói függőség elkerülése érdekében)
A 6.3.5 pont előírja:
A biztonságos törlési eljárások megerősítése a fiók lezárása előtt
Ezeknek a követelményeknek a beszállítói életciklus elején kell megjelenniük. Ne a megszüntetéskor kérdezze meg, hogy exportálhatók-e az adatok. Ne a fiók lezárásakor kérdezze meg, hogy létezik-e törlési bizonyíték.
Egy gyakorlati DORA felhőkilépési tesztnek a következőket kell tartalmaznia:
- Reprezentatív adatkészlet exportálása a megállapodott formátumban.
- A teljesség, sértetlenség, időbélyegek, metaadatok és hozzáférési kontrollok ellenőrzése.
- Az adatkészlet importálása előéles környezetbe vagy alternatív eszközbe.
- A titkosítási kulcsok kezelésének és a titkok rotációjának megerősítése.
- A naplóexport és az auditnyom megőrzésének megerősítése.
- A szolgáltató törlési eljárásainak dokumentálása, beleértve a biztonsági mentések megőrzését és a törlés tanúsítását.
- Problémák, helyesbítő intézkedések, felelősök és határidők rögzítése.
- A beszállítói kockázatértékelés, az alkalmazhatósági nyilatkozat és a kilépési terv frissítése.
A hordozhatóság nem beszerzési ígéret. Tesztelt képesség.
Egyhetes sprint auditra alkalmas DORA kilépési tervhez
Vegyünk példaként egy fizetési intézményt, amely SaaS csaláselemző szolgáltatót használ. A szolgáltató tranzakciós adatokat, ügyfélazonosítókat, eszköztelemetriát, viselkedési jeleket, csalási szabályokat, pontozási kimeneteket és ügyirat-megjegyzéseket fogad be. A szolgáltatás kritikus csalásészlelési folyamatot támogat. A cég emellett felhőalapú adattárházat használ az exportált elemzési eredmények tárolására.
A CISO olyan DORA IKT-kilépési stratégiát szeretne, amely megállja a helyét a belső audit és a felügyeleti felülvizsgálat során. Egy egyhetes sprint feltárhatja a hiányosságokat és felépítheti a bizonyítékláncot.
1. nap: a beszállító besorolása és a kilépési forgatókönyv meghatározása
A Zenith Blueprint Kontrollok működésben fázisának 23. lépését, az 5.19–5.37 kontrollokhoz tartozó teendőket használva a csapat a beszállítói portfólió felülvizsgálatával és besorolásával kezdi:
Állítsa össze a jelenlegi beszállítók és szolgáltatók teljes listáját (5.19), és sorolja be őket a rendszerekhez, adatokhoz vagy operatív kontrollhoz való hozzáférésük alapján. Minden besorolt beszállító esetében ellenőrizze, hogy a biztonsági elvárások egyértelműen be vannak-e építve a szerződésekbe (5.20), beleértve a bizalmasságot, a hozzáférést, az incidensbejelentést és a megfelelési kötelezettségeket.
A beszállító kritikusnak minősül, mert kritikus vagy fontos funkciót támogat, érzékeny működési adatokat kezel, és befolyásolja a tranzakciómonitorozási eredményeket.
A csapat három kilépési kiváltó okot határoz meg:
- A szolgáltató fizetésképtelensége vagy a szolgáltatás megszüntetése.
- Lényeges biztonsági incidens vagy bizalomvesztés.
- Stratégiai migráció a koncentrációs kockázat csökkentése érdekében.
2. nap: a követelményjegyzék és a kockázati bejegyzés felépítése
A csapat egyetlen követelményjegyzéket hoz létre, amely lefedi a DORA szerinti harmadik fél által jelentett IKT-kockázatot, az ISO/IEC 27001:2022 beszállítói és felhőkontrollokat, a személyes adatokra vonatkozó GDPR-kötelezettségeket, az ügyfélszerződéses vállalásokat és a belső kockázatvállalási hajlandóságot.
A GDPR alapján a vállalat megerősíti, hogy a tranzakcióazonosítók, eszközazonosítók, helyadat-jelek és viselkedéselemzések kapcsolódnak-e azonosított vagy azonosítható személyekhez. A GDPR Article 5 szerinti elvek, beleértve a sértetlenséget, bizalmasságot, tárolási korlátozást és elszámoltathatóságot, a kilépési bizonyítékok követelményének részévé válnak. Ha a kilépés új szolgáltatóhoz történő továbbítással jár, dokumentálni kell a jogalapot, a célt, az adattakarékosságot, a megőrzést, az adatfeldolgozói feltételeket és a védelmi intézkedéseket.
A kockázati bejegyzés a következőket tartalmazza:
| Kockázati elem | Példabejegyzés |
|---|---|
| Kockázati állítás | A csaláselemző szolgáltatóból való kilépés képtelensége a hatástűrési határidőn belül |
| Következmény | Késedelmes csalásészlelés, pénzügyi veszteség, szabályozási jogsértés, ügyfélkár |
| Valószínűség | Közepes, a szolgáltatói koncentráció és a saját formátumok alapján |
| Kockázattulajdonos | Pénzügyi bűnözés elleni technológiai vezető |
| Kezelés | Szerződésmódosítás, exportteszt, alternatív szolgáltató értékelése, biztonsági mentés ellenőrzése, runbook-teszt |
| Maradványkockázat jóváhagyása | CRO-jóváhagyás a tesztbizonyítékok és a helyesbítő intézkedések felülvizsgálata után |
3. nap: szerződéses hiányosságok javítása
A jogi és beszerzési terület összeveti a szerződést a Clarysec beszállítói záradékaival. Hozzáadják az átállási támogatást, a szolgáltatás folytatását egy meghatározott átállási időszak alatt, az audithoz és bizonyítékokhoz való hozzáférést, az alvállalkozói értesítést, az adatexport-formátumot, a biztonságos törlés tanúsítását, az incidens-együttműködést és a helyreállítási időre vonatkozó vállalásokat.
Az Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat „A szabályzat végrehajtásának követelményei” szakaszának 6.5.1 pontja kimondja:
A kritikus beszállítókkal kötött szerződéseknek tartalmazniuk kell folytonossági kötelezettségeket és helyreállítási időre vonatkozó vállalásokat.
KKV-k esetében az Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat-sme Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat – KKV „Kockázatkezelés és kivételek” szakaszának 7.2.1.4 pontja előírja a csapatok számára, hogy:
dokumentálják az ideiglenes beszállítói vagy partnerhelyettesítési terveket
Ez a záradék a „migrálni fogunk” kijelentést végrehajtható tartalék megoldássá alakítja: melyik szolgáltató, melyik belső kerülőeljárás, melyik manuális folyamat, melyik adatkivonat, melyik felelős és melyik jóváhagyási útvonal.
4. nap: az adathordozhatóság és a biztonsági mentésből történő helyreállíthatóság tesztelése
A technológiai csapat exportálja a csalási szabályokat, ügyadatokat, tranzakciós pontozási kimeneteket, naplókat, konfigurációt, API-dokumentációt és aktív felhasználói listákat. Tesztelik, hogy az adatok helyreállíthatók vagy újra felhasználhatók-e szabályozott környezetben.
A Biztonsági mentési és helyreállítási szabályzat-sme Biztonsági mentési és helyreállítási szabályzat – KKV „Irányítási követelmények” szakaszának 5.3.3 pontja előírja:
A helyreállítási teszteket legalább negyedévente el kell végezni, és az eredményeket dokumentálni kell a helyreállíthatóság ellenőrzése érdekében
A vállalati Biztonsági mentési és helyreállítási szabályzat Biztonsági mentési és helyreállítási szabályzat „Betartatás és megfelelés” szakaszának 8.3.1 pontja hozzáteszi:
Időszakosan auditálni kell a biztonsági mentési naplókat, konfigurációs beállításokat és teszteredményeket
A Zenith Blueprint Kontrollok működésben fázisának 19. lépésében, a 8.13 kontrollnál a Clarysec figyelmeztet, miért számít ez:
A helyreállítási tesztelés az a terület, ahol a legtöbb szervezet elmarad. Az a biztonsági mentés, amely nem állítható helyre időben vagy egyáltalán, kötelezettség, nem pedig vagyonelem. Ütemezzen rendszeres helyreállítási gyakorlatokat, akár csak részlegeseket is, és dokumentálja az eredményt.
A csapat feltárja, hogy az exportált ügyirat-megjegyzések nem tartalmazzák a csatolmányokat, és az API sebességkorlátozásai miatt a teljes export túl lassú a meghatározott helyreállítási célhoz képest. A problémát naplózzák, felelőshöz rendelik, majd szerződéskiegészítéssel és műszaki export-újratervezéssel helyesbítik.
5. nap: a kilépési asztali gyakorlat és a bizonyítékok felülvizsgálata
A csapat asztali gyakorlatot hajt végre: a beszállító egy jelentős incidens után 90 napos felmondást jelent be. Az üzemeltetésnek fenn kell tartania a csalásmonitorozást, miközben az adatok migrálása zajlik.
A Zenith Blueprint Kontrollok működésben fázisának 23. lépésében, az 5.30 kontrollnál a Clarysec elmagyarázza a tesztelési elvárást:
Az IKT-felkészültség jóval a zavar bekövetkezése előtt kezdődik. Magában foglalja a kritikus rendszerek azonosítását, kölcsönös függőségeik megértését és üzleti folyamatokhoz történő hozzárendelésüket.
Ugyanez a szakasz hozzáteszi:
Az üzletmenet-folytonossági tervben meghatározott helyreállítási időcélokat (RTO-k) és helyreállítási pont célértékeket (RPO-k) tükrözniük kell a műszaki konfigurációknak, szerződéseknek és infrastruktúra-tervezésnek.
A bizonyítékcsomag tartalmazza a beszállítói besorolást, a kockázatértékelést, a szerződéses záradékokat, a kilépési runbookot, az adatexport eredményeit, a biztonsági mentésből történő helyreállítás bizonyítékát, a törlési eljárást, az alternatív szolgáltató értékelését, az asztali gyakorlat jegyzőkönyvét, a helyesbítő intézkedési naplót, a vezetői jóváhagyást és a maradványkockázati döntést.
A CISO most már bizonyítékokkal, nem optimizmussal tud válaszolni az igazgatóság kérdésére.
Keresztmegfelelés: egy kilépési terv, több auditori nézőpont
Egy erős DORA kilépési stratégia csökkenti a párhuzamos megfelelési munkát az ISO/IEC 27001:2022, NIS2, GDPR, NIST és COBIT 2019 irányítási elvárások mentén.
| Keretrendszer vagy jogszabály | Mit kér a kilépéstervezés nyelvére lefordítva | A Clarysec által javasolt bizonyíték |
|---|---|---|
| DORA | Kilépési stratégiák fenntartása kritikus vagy fontos IKT-szolgáltatásokra, a harmadik fél által jelentett kockázat kezelése, reziliencia tesztelése, szerződések és függőségek dokumentálása | Beszállítói nyilvántartás, kritikussági besorolás, szerződéses záradékok, kilépési teszt, átállási terv, auditálási jogok, koncentrációs kockázatértékelés |
| NIS2 | Releváns szervezetek esetében az ellátásilánc-biztonság, üzletmenet-folytonosság, biztonsági mentés, katasztrófa utáni helyreállítás, válságkezelés, incidenskezelés és irányítási elszámoltathatóság kezelése | Beszállítói kockázatértékelés, folytonossági terv, incidenskezelési forgatókönyvek, vezetői jóváhagyás, helyesbítő intézkedések |
| GDPR | Személyes adatok védelme továbbítás, visszaadás, törlés, migráció és megőrzés során elszámoltathatósággal és megfelelő technikai és szervezési intézkedésekkel | Adattérkép, adatfeldolgozói feltételek, exportbizonyíték, törlési tanúsítás, megőrzési szabályok, incidenskezelési összhang |
| ISO/IEC 27001:2022 | Beszállítói, felhő-, folytonossági, incidens-, audit-, monitorozási és fejlesztési kontrollok működtetése az IBIR-en belül | Alkalmazhatósági nyilatkozat, kockázatkezelési terv, belső audit bejegyzés, vezetőségi felülvizsgálat, dokumentált eljárások |
| NIST Cybersecurity Framework 2.0 | Külső függőségek irányítása, beszállítók azonosítása, szolgáltatások védelme, zavarokra való reagálás és működés helyreállítása | Függőségi leltár, beszállítói kockázati bejegyzések, védelmi kontrollok, reagálási eljárás, helyreállítási teszt, levont tanulságok |
| COBIT 2019 | Az ellátás, beszállítói teljesítmény, kockázat, szolgáltatás-folytonosság, bizonyosság és megfelelés feletti irányítás igazolása | Irányítási döntések, felelősség, KPI-k, beszállítói felügyelet, folytonossági bizonyítékok, bizonyossági jelentések |
A lényeg nem az, hogy az egyik keretrendszer kiváltja a másikat. Az érték abban áll, hogy egy jól kialakított IBIR lehetővé teszi a szervezet számára, hogy egyszer hozza létre a bizonyítékokat, majd célzottan újra felhasználja őket.
A Clarysec Zenith Controls azzal segíti a csapatokat ezekre az auditori nézőpontokra való felkészülésben, hogy az ISO/IEC 27001:2022 kontrollokat auditbizonyítékokhoz és keretrendszerek közötti elvárásokhoz kapcsolja.
| Auditori nézőpont | Valószínű auditori kérdés | A kérdést általában kielégítő bizonyíték |
|---|---|---|
| ISO/IEC 27001:2022 auditor | Kontrollált-e a beszállítói és felhőből való kilépés az IBIR-en, a kockázatértékelésen, az alkalmazhatósági nyilatkozaton és a belső auditprogramon belül? | IBIR alkalmazási területe, kockázatértékelés, alkalmazhatósági nyilatkozat, beszállítói eljárás, felhőkilépési eljárás, belső audit eredményei, vezetőségi felülvizsgálati intézkedések |
| DORA felügyelet vagy belső DORA audit | Ki tud-e lépni a szervezet egy kritikus IKT-szolgáltatóból elfogadhatatlan zavar, adatvesztés vagy szabályozási jogsértés nélkül? | Kritikussági értékelés, DORA beszállítói nyilvántartás, kilépési stratégia, szerződéses záradékok, átállási teszt, koncentrációs értékelés, helyesbítő intézkedési napló |
| NIST-orientált értékelő | Irányították és azonosították-e a külső függőségeket, védték-e a kritikus szolgáltatásokat, és tesztelték-e a reagálási és helyreállítási képességeket? | Függőségi leltár, hozzáférés-szabályozás, monitorozás, incidenseszkaláció, helyreállítási teszt, levont tanulságok |
| COBIT 2019 vagy ISACA auditor | Irányított, felelőshöz rendelt, mért és bizonyossággal alátámasztott-e a beszállítói kilépés olyan menedzsmentcélokon keresztül, mint az APO10 Managed Vendors és a DSS04 Managed Continuity? | RACI, vezetői jóváhagyás, KPI-k, beszállítói teljesítmény-felülvizsgálat, bizonyossági bizonyíték, problémakövetés |
| Adatvédelmi auditor | Visszaadhatók, migrálhatók, korlátozhatók, törölhetők vagy biztonságosan megőrizhetők-e a személyes adatok a GDPR-kötelezettségek szerint? | Adatkezelési nyilvántartás, adatfeldolgozói záradékok, exportbizonyíték, törlési tanúsítvány, megőrzési indoklás, incidenskezelési munkafolyamat |
Gyakori audithiba a bizonyítékok széttöredezettsége. A beszállítói kapcsolattartónál van a szerződés. Az IT-nél vannak a biztonsági mentési naplók. A jogi területnél van az adatfeldolgozási szerződés. A kockázatkezelésnél van az értékelés. A megfelelési területnél van a szabályozási leképezés. Senkinél nincs meg a teljes történet.
A Clarysec ezt úgy oldja meg, hogy a bizonyítékcsomagot a kilépési forgatókönyv köré tervezi. Minden dokumentum egy auditori kérdésre válaszol: melyik szolgáltatásból történik kilépés, miért kritikus, milyen adatok és rendszerek érintettek, ki a kockázattulajdonos, milyen szerződéses jogok teszik lehetővé a kilépést, milyen műszaki mechanizmusok teszik lehetővé a migrációt, milyen folytonossági megoldások tartják működésben az üzletet, milyen teszt igazolja, hogy a terv működik, milyen problémákat helyesbítettek, és ki hagyta jóvá a maradványkockázatot.
A Clarysec DORA kilépési stratégia ellenőrzőlistája
Ezzel az ellenőrzőlistával a DORA IKT-kilépési stratégia dokumentumból auditálható kontrollkészletté alakítható.
| Kontrollterület | Minimális elvárás | Megőrzendő bizonyíték |
|---|---|---|
| Beszállítói besorolás | Annak azonosítása, hogy a beszállító kritikus vagy fontos funkciókat támogat-e | Beszállítói nyilvántartás, kritikussági döntés, függőségi térkép |
| Szerződéses érvényesíthetőség | Átállási támogatás, adatexport, törlés, audit, incidens-együttműködés és folytonossági kötelezettségek beépítése | Szerződéses záradékok, kiegészítések, jogi felülvizsgálat |
| Felhőbeli hordozhatóság | Exportképesség megerősítése a beléptetés előtt és időszakosan az üzemelés során | Exportteszt-eredmények, adatformátum-dokumentáció, migrációs megjegyzések |
| Adatvédelem | Személyes adatok visszaadásának, törlésének, megőrzésének, továbbításának és adatfeldolgozói kötelezettségeinek kezelése | Adattérkép, DPA, törlési tanúsítás, megőrzési döntés |
| Biztonsági mentés és helyreállítás | Helyreállíthatóság tesztelése az RTO és RPO alapján | Helyreállítási naplók, tesztjelentés, helyesbítő intézkedési bejegyzés |
| Helyettesítési tervezés | Alternatív szolgáltató, manuális kerülőeljárás vagy belső folyamat meghatározása | Helyettesítési terv, asztali gyakorlat jegyzőkönyvei, felelőslista |
| Irányítás | Kockázattulajdonos kijelölése és vezetői jóváhagyás | Kockázati bejegyzés, maradványkockázat elfogadása, vezetőségi felülvizsgálati jegyzőkönyvek |
| Auditkészség | Szabályzatok, kontrollok, szerződések, tesztek és helyesbítő intézkedések összekapcsolása | Bizonyítékcsomag-index, belső auditjelentés, problémakövető |
Tegye a kilépéstervezést igazgatósági szinten értelmezhető rezilienciakontrollá
Ha a DORA kilépési stratégia csak egy szerződéses záradék, akkor nem áll készen. Ha a biztonsági mentést még soha nem állították helyre, akkor nem áll készen. Ha a felhőszolgáltató képes adatokat exportálni, de senki sem ellenőrizte a teljességet, akkor nem áll készen. Ha az igazgatóság nem látja a maradványkockázati döntést, akkor nem áll készen.
A Clarysec segít a CISO-knak, megfelelési vezetőknek, auditoroknak és üzleti tulajdonosoknak olyan DORA IKT-kilépési stratégiák kialakításában, amelyek gyakorlatiak, arányosak és auditálhatók. A megvalósítás ütemezéséhez a Zenith Blueprint Zenith Blueprint, a keresztmegfelelési leképezéshez a Zenith Controls Zenith Controls, valamint olyan szabályzatsablonok kombinációját használjuk, mint a Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat, a Felhőszolgáltatások használatára vonatkozó szabályzat – KKV Felhőszolgáltatások használatára vonatkozó szabályzat – KKV, a Harmadik fél és beszállítói biztonsági szabályzat – KKV Harmadik fél és beszállítói biztonsági szabályzat – KKV, valamint az Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat Üzletmenet-folytonossági és katasztrófa utáni helyreállítási szabályzat, hogy teljes, kontrolltól bizonyítékig tartó láncot hozzunk létre.
A következő lépés egyszerű és nagy értékű: válasszon ki ezen a héten egy kritikus IKT-beszállítót. Sorolja be, vizsgálja felül a szerződését, teszteljen egy adatexportot, ellenőrizzen egy helyreállítást, dokumentáljon egy helyettesítési tervet, és hozzon létre egy bizonyítékcsomagot.
Ez az egyetlen gyakorlat megmutatja, hogy a DORA kilépési stratégia valódi rezilienciaképesség-e, vagy csak egy dokumentum, amely az audit során fog megbukni.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
