A kérdőíven túl: információbiztonsági vezetői útmutató a magas kockázatú beszállítók auditálásához NIS2 és DORA szerint

A jelentés halk puffanással érkezett Maria Valen információbiztonsági vezető asztalára, de a hang inkább riasztásnak tűnt. A közelgő DORA megfelelőségi felülvizsgálat előzetes auditértékelése volt, amelyben egy sort élénk pirossal emeltek ki: „Elégtelen bizonyosság a kritikus harmadik fél szolgáltató, a CloudSphere tekintetében.”

A CloudSphere nem egyszerű beszállító volt. Ők biztosították a vállalat új digitális banki platformjának gerincét, naponta több millió tranzakciót feldolgozva. Maria rendelkezett a beszállító ISO/IEC 27001:2022 tanúsítványával. Megvolt a kitöltött biztonsági kérdőívük is, egy vaskos, 200 kérdéses dokumentum. Az előzetes auditot végzők azonban azt jelezték, hogy egy magas kockázatú, kritikus beszállító esetében a jelölőnégyzet-alapú megfelelés már nem elég. A szabályok megváltoztak.

Mivel a NIS2 irányelv és a DORA már teljes körűen hatályban van, a szabályozó hatóságok túllépnek a papíralapú megfelelési nyomvonalon. Kézzelfogható bizonyítékot várnak el a kellő gondosságról, a folyamatos monitorozásról és a teljes ellátási lánc feletti erős irányításról. Maria kihívása ma minden információbiztonsági vezető kihívása: hogyan lehet a kérdőíven túl valóban auditálni és biztonságossá tenni a legkritikusabb beszállítókat? Ehhez stratégiai váltás szükséges: a passzív ellenőrzés helyett aktív, bizonyítékokon alapuló bizonyosságra kell építeni.

A statikus kérdőív hibája egy dinamikus világban

Évekig a biztonsági kérdőív volt a harmadik felek kockázatkezelésének alapköve. Csakhogy ez csupán statikus pillanatfelvétel egy dinamikus fenyegetési környezetben. A beszállító kockázati profilja nem állandó; minden új fenyegetéssel, rendszerváltozással vagy bevont alvállalkozóval változik. Egy olyan kritikus beszállító, mint a CloudSphere esetében kizárólag önértékelésre támaszkodni olyan, mintha viharban a tavalyi időjárási térképpel navigálnánk.

A NIS2 irányelv kifejezetten kockázatalapú megközelítést ír elő, és megköveteli, hogy a biztonsági intézkedések arányosak legyenek a tényleges kockázatokkal. Ez azt jelenti, hogy az egységes, mindenkire azonos módon alkalmazott kérdőív alapvetően nincs összhangban a mai szabályozói elvárásokkal. Elmúltak azok az idők, amikor egy tanúsítvány vagy egy kitöltött ellenőrzőlista bizonyíték helyett elfogadható volt. A valódi kockázat a papíralapú megfelelési nyomvonalon túl található.

Itt válik nélkülözhetetlenné a strukturált, életciklus-alapú megközelítés. Nem a kérdőívek elhagyásáról van szó, hanem arról, hogy a valóban kritikus beszállítók esetében mélyebb, érdemi ellenőrzéssel kell kiegészíteni őket. Ez az alapelv jelenik meg a Clarysec Harmadik felekre és beszállítói biztonságra vonatkozó szabályzatában. Egyik alapvető célkitűzése:

„Formális kellő gondosságot és dokumentált kockázatértékeléseket kell megkövetelni új beszállítók bevonása vagy magas kockázatú szolgáltatási megállapodások megújítása előtt.”

• Az „Célkitűzések” szakasz 3.3 szabályzati pontjából

Ez a pont az egyszerű ellenőrzésről a formális vizsgálatra helyezi át a szemléletet, ami kulcsfontosságú első lépés egy szabályozói vizsgálat előtt is védhető program kialakításában.

Beszállítói kockázat NIS2 és DORA szerint: az új elvárások

A NIS2 és a DORA egyaránt megköveteli, hogy a szervezetek szisztematikusan azonosítsák, értékeljék és folyamatosan nyomon kövessék a beszállítói környezetükben jelentkező kockázatokat. A beszállítókezelést beszerzési funkcióból az operatív reziliencia és az információbiztonság egyik központi pillérévé emelik.

Az új szabályozói környezet egyértelmű, az ISO/IEC 27001:2022-höz hasonló elismert szabványokhoz szorosan illeszkedő keretrendszereket vár el. Az alábbi táblázat magas szintű összefoglalót ad arról, hogy ezek a keretrendszerek mit várnak el a beszállítói irányítási programtól:

Egy erős beszállítói auditprogramot nem kell nulláról felépíteni. Az ISO/IEC 27001:2022 keretrendszer, különösen annak Annex A kontrolljai, hatékony mintát ad. A Clarysec ügyfeleit arra irányítjuk, hogy programjukat három összekapcsolódó kontroll köré építsék, amelyek teljes beszállítói irányítási életciklust alkotnak.

Védhető auditkeretrendszer kialakítása: az ISO 27001:2022 életciklus

A szabályozói elvárásoknak megfelelő programhoz strukturált, globálisan elismert szabványon alapuló megközelítés szükséges. Az ISO/IEC 27001:2022 beszállítói biztonsági kontrolljai életciklust biztosítanak a harmadik felek kockázatának kezelésére a kapcsolat kezdetétől annak megszűnéséig. Nézzük meg, hogyan használhatja Maria ezt az életciklust a CloudSphere-re vonatkozó, védhető auditterv kialakításához.

1. lépés: Az alapok – Információbiztonság a beszállítói kapcsolatokban (5.19)

Az 5.19 kontroll a stratégiai kiindulópont. Formális folyamatok létrehozását írja elő a teljes beszállítói ökoszisztémához kapcsolódó információbiztonsági kockázatok azonosítására, értékelésére és kezelésére. Itt kell meghatározni, mit jelent a „magas kockázat” a szervezet számára, és itt kell lefektetni az alapvető játékszabályokat.

A Clarysec Zenith Controls: több megfelelési keretrendszert összekapcsoló útmutatója részletesen bemutatja az 5.19 kontrollt, és szemlélteti, hogyan működik a beszállítói irányítás központi csomópontjaként. Ez a kontroll szorosan kapcsolódik más kontrollokhoz, például az 5.21 (Információbiztonság az IKT-ellátási láncban) kontrollhoz, amely a hardver- és szoftverkomponenseket fedi le, valamint az 5.14 (Információtovábbítás) kontrollhoz, amely a biztonságos adatcserét szabályozza. Egy beszállítói kapcsolat nem kezelhető hatékonyan anélkül, hogy a beszállító által biztosított technológiát és a megosztott adatokat is kontroll alatt tartanánk.

Maria számára ez azt jelenti, hogy a CloudSphere auditja nem állhat meg a vállalati kockázati helyzet áttekintésénél; ki kell terjednie a ténylegesen nyújtott platform biztonságára is. A Zenith Controls útmutató kiemeli, hogy az 5.19 erős bevezetése közvetlenül támogatja a főbb szabályozásoknak való megfelelést:

• NIS2 (Article 21(2)(d)): Kötelezi a szervezeteket az ellátásilánc-kockázat kezelésére a biztonsági keretrendszer alapvető részeként.
• DORA (Articles 28–30): Erős IKT-harmadik fél kockázatkezelési keretrendszert ír elő, beleértve a kritikussági besorolást és a szerződéskötést megelőző kellő gondosságot.
• GDPR (Article 28): Megköveteli, hogy az adatkezelők kizárólag olyan adatfeldolgozókat vegyenek igénybe, amelyek megfelelő garanciákat nyújtanak az adatvédelemre.

Ez a kontroll előírja a beszállítói kockázati besorolást, a folyamatos monitorozást és az időben történő hozzáférés-visszavonást. Célja annak biztosítása, hogy a biztonság a beszállítói életciklus szerves része legyen, ne utólag hozzáillesztett elem.

2. lépés: A kikényszerítés – Az információbiztonság kezelése a beszállítói megállapodásokban (5.20)

Az a biztonsági követelmény, amely nem szerepel a szerződésben, legfeljebb ajánlás. Az 5.20 kontroll az a pont, ahol az irányítás szerződéses alapon kikényszeríthetővé válik. Magas kockázatú beszállító esetén a szerződés a legerősebb auditeszköz.

Ahogy a Zenith Controls hangsúlyozza, ezeknek a megállapodásoknak egyértelműnek kell lenniük. Az „iparági legjobb gyakorlatoknak megfelelő biztonságra” vonatkozó homályos ígéretek értéktelenek. Egy CloudSphere-hez hasonló beszállító esetében Mariának ellenőriznie kell, hogy a szerződés konkrét, mérhető záradékokat tartalmaz-e, amelyek tényleges felügyeletet biztosítanak a szervezet számára:

• Auditálási jog: Olyan záradék, amely kifejezetten jogot ad a szervezetnek technikai értékelések végzésére, bizonyítékok áttekintésére vagy harmadik fél megbízására az audit elvégzéséhez.
• Incidensbejelentési határidők: Konkrét, szigorú határidők — például az észleléstől számított 24 órán belül — a biztonsági incidens bejelentésére, nem csupán egy homályos „indokolatlan késedelem nélkül” fordulat.
• Alvállalkozó- vagy negyedik fél-kezelés: Olyan záradék, amely előírja, hogy a beszállító a saját kritikus alvállalkozóira is érvényesítse ugyanazokat a biztonsági követelményeket, és minden változásról értesítse a szervezetet. Ez kulcsfontosságú az alvállalkozói láncban jelentkező kockázatok kezeléséhez.
• Biztonságos kilépési stratégia: Egyértelmű kötelezettségek az adatok visszaszolgáltatására vagy tanúsított megsemmisítésére a szerződés megszűnésekor.

A DORA ezen a ponton különösen előíró jellegű. Az Article 30 kötelező szerződéses rendelkezéseket sorol fel, beleértve az auditorok és szabályozó hatóságok akadálytalan hozzáférését, a szolgáltatási helyszínek konkrét adatait és az átfogó kilépési stratégiákat. Az auditorok mintavétellel ellenőrzik a magas kockázatú beszállítói szerződéseket, és közvetlenül vizsgálják e záradékok meglétét.

3. lépés: A folyamatos kör – Beszállítói szolgáltatások monitorozása, felülvizsgálata és változáskezelése (5.22)

Az életciklus utolsó eleme az 5.22 kontroll, amely a beszállítói felügyeletet egyszeri ellenőrzésből folyamatos folyamattá alakítja. Az audit nem lehet meglepetésszerű esemény; a transzparensen működő, folyamatos kapcsolat egyik ellenőrzési pontjának kell lennie.

Itt marad el sok szervezet. Aláírják a szerződést, majd irattárba teszik. Magas kockázatú beszállítók esetében azonban a valódi munka a beléptetés után kezdődik. A Zenith Controls útmutató az 5.22 kontrollt olyan kritikus operatív folyamatokhoz kapcsolja, mint a 8.8 (Műszaki sérülékenységek kezelése) és az 5.29 (Információbiztonság üzemzavar alatt). Ez azt jelenti, hogy a hatékony monitorozás jóval több, mint egy éves felülvizsgálati értekezlet. Magában foglalja:

• Harmadik féltől származó bizonyítékok felülvizsgálata: SOC 2 Type II jelentések, ISO 27001 felügyeleti audit eredmények vagy penetrációs tesztelési összefoglalók aktív bekérése és elemzése. A lényeg a kivételek áttekintése és a korrekciós intézkedések nyomon követése.
• Incidensek monitorozása: A beszállítót érintő nyilvánosan közzétett adatsértések vagy biztonsági incidensek nyomon követése, valamint a szervezetre gyakorolt lehetséges hatás formális értékelése.
• Változáskezelés: Olyan folyamat bevezetése, amelyben a beszállító szolgáltatásának minden lényeges változása — például új adatközpont-helyszín vagy új kritikus alvállalkozó — automatikusan kockázati újraértékelést indít.

A Clarysec Zenith Blueprint: auditori 30 lépéses ütemterv gyakorlati útmutatást ad ehhez, különösen a 24. lépésben, amely az alvállalkozói kockázattal foglalkozik. Az útmutató szerint:

„Minden kritikus beszállító esetében azonosítani kell, hogy használ-e olyan alvállalkozókat vagy al-adatfeldolgozókat, akik hozzáférhetnek az Ön adataihoz vagy rendszereihez. Dokumentálni kell, hogyan érvényesülnek az Ön információbiztonsági követelményei ezeknél a feleknél… Ahol megvalósítható, kérni kell a kulcsfontosságú alvállalkozók listáját, és biztosítani kell, hogy az auditálási jog vagy a bizonyosság megszerzésének lehetősége rájuk is kiterjedjen.”

Ez Maria számára kulcskérdés. Használ-e a CloudSphere harmadik fél adatelemző vállalatot? Jelentős nyilvános felhőszolgáltatónál üzemel-e az infrastruktúrájuk? Ezek az alsóbb szintű függőségek jelentős, gyakran láthatatlan kockázatot képviselnek, amelyet az auditnak felszínre kell hoznia.

Az elmélettől a gyakorlatig: Maria gyakorlati auditterve a CloudSphere-re

Az ISO 27001:2022 életciklusra támaszkodva Maria csapata új audittervet készít a CloudSphere-re, amely messze túlmutat a kérdőíven, és bemutatja a szabályozó hatóságok által elvárt érett, kockázatalapú irányítást.

1. Szerződés-felülvizsgálat: A meglévő CloudSphere-szerződést a DORA Article 30 és az 5.20 kontroll bevált gyakorlatai alapján feltérképezik. Hiányelemzési jelentést készítenek a következő megújítási ciklus támogatására és az aktuális audit fókuszterületeinek priorizálására.

2. Célzott bizonyítékkérés: Általános kérdőív helyett formális kérelmet küldenek konkrét bizonyítékokra, többek között:

   • a legfrissebb SOC 2 Type II jelentésre és annak összefoglalójára, hogy a feltárt kivételeket hogyan kezelték;
   • a legutóbbi külső penetrációs teszt vezetői összefoglalójára;
   • minden olyan alvállalkozó — negyedik fél — teljes listájára, aki adatokat kezel vagy azokhoz hozzáfér;
   • annak bizonyítékára, hogy a biztonsági követelményeket szerződésesen továbbvezették ezekre az alvállalkozókra;
   • olyan naplókra vagy jelentésekre, amelyek igazolják a kritikus sérülékenységek — például Log4j, MOVEit — időben történő javítását az elmúlt hat hónapban.

3. Technikai ellenőrzés: Érvényesítik az „auditálási jog” záradékot, és technikai mélyelemzési alkalmat ütemeznek a CloudSphere biztonsági csapatával. A napirend az incidensreagálási forgatókönyvekre, a Cloud Security Posture Management (CSPM) eszközökre és az adatvesztés-megelőzési kontrollokra fókuszál.

4. Formális kivételkezelés: Ha a CloudSphere bizonyos bizonyítékok megadását elutasítja, Maria felkészült. A szervezet irányítási folyamata, amelyet a Harmadik felekre és beszállítói biztonságra vonatkozó szabályzat rögzít, egyértelmű:

„A magas kockázatú kivételeket — például szabályozott adatot kezelő vagy kritikus rendszereket támogató beszállítók esetében — az információbiztonsági vezetőnek, a jogi területnek és a beszerzési vezetésnek kell jóváhagynia, és rögzíteni kell az ISMS kivételnyilvántartásban.”

• A „Kockázatkezelés és kivételek” szakasz 7.3 szabályzati pontjából

Ez biztosítja, hogy a bizonyítékok megadásának megtagadását ne hagyják egyszerűen figyelmen kívül, hanem a szervezet legmagasabb szintjein formálisan elfogadott kockázatként kezeljék — ez olyan folyamat, amelyet az auditorok is elfogadnak.

Az auditor nézőpontja: mit várnak el a különböző auditorok?

Valóban reziliens program kialakításához auditorként kell gondolkodni. A különböző auditkeretrendszerek eltérő szempontrendszert alkalmaznak, és a kérdéseik előzetes felismerése kulcsfontosságú a sikerhez. Az alábbi összefoglaló bemutatja, mit várnának el a különböző auditorok a beszállítói irányítási program áttekintésekor:

Ez a több nézőpontú megközelítés megmutatja, hogy egy erős program nem egyetlen szabvány teljesítéséről szól, hanem olyan átfogó irányítási keretrendszer kialakításáról, amely minden érintett számára előállítja a szükséges bizonyítékokat.

Kritikus buktatók: hol buknak el a beszállítói auditok?

Sok beszállítói felügyeleti program gyakori, elkerülhető hibák miatt marad el az elvárt szinttől. Különösen figyeljen az alábbi kritikus buktatókra:

• Az audit eseményként kezelése: Egyszeri beléptetési vagy megújítási auditokra támaszkodás folyamatos monitorozás bevezetése helyett.
• Tanúsítási önelégültség: ISO vagy SOC 2 tanúsítvány elfogadása önmagában, a jelentés részleteinek, hatókörének és kivételeinek áttekintése nélkül.
• Homályos szerződések: Kifejezett, kikényszeríthető záradékok hiánya az auditálási jogokra, az incidensbejelentésre és az adatkezelésre vonatkozóan.
• Gyenge nyilvántartás-kezelés: A szervezet nem képes teljes, kockázati szintek szerint besorolt beszállítói nyilvántartást előállítani az összes beszállítóról és az általuk elért adatokról.
• Az alvállalkozói lánc kockázatainak figyelmen kívül hagyása: A beszállító saját kritikus alvállalkozói — negyedik fél kockázat — által okozott kockázatok azonosításának és kezelésének elmulasztása.
• Ellenőrizetlen sérülékenységkezelés: Annak feltételezése, hogy a beszállító javítja a kritikus sérülékenységeket, bizonyíték bekérése nélkül.

Gyakorlati ellenőrzőlista magas kockázatú beszállítói auditokhoz

Használja ezt a Zenith Blueprint alapján adaptált ellenőrzőlistát annak biztosítására, hogy minden magas kockázatú beszállító auditfolyamata alapos és védhető legyen.

Következtetés: reziliens és védhető ellátási lánc kialakítása

A kritikus beszállítók jelölőnégyzet-alapú megfelelésének korszaka véget ért. A NIS2 és a DORA által meghatározott intenzív szabályozói vizsgálat alapvető váltást követel meg a folyamatos, bizonyítékokon alapuló bizonyossági modell felé. Mariához hasonló információbiztonsági vezetőknek kell átvezetniük szervezeteiket a statikus kérdőíven túlra.

Az ISO/IEC 27001:2022 kontrollok bevált életciklusára épített programmal olyan keretrendszer jön létre, amely nemcsak megfelel, hanem ténylegesen csökkenti a kockázatot. Ez azt jelenti, hogy a beszállítói biztonságot stratégiai szakterületként kell kezelni, a kikényszeríthető követelményeket be kell építeni a szerződésekbe, és a kapcsolat teljes időtartama alatt éber felügyeletet kell fenntartani.

Szervezete biztonsága csak annyira erős, mint a leggyengébb láncszem, és a mai összekapcsolt ökoszisztémában ez a láncszem gyakran egy harmadik fél. Ideje visszavenni az irányítást.

Készen áll arra, hogy túllépjen a kérdőíven?

A Clarysec integrált eszközkészletei biztosítják azt az alapot, amelyre világszínvonalú, bármely auditon helytálló beszállítói kockázatkezelési program építhető.

• Töltse le szabályzatsablonjainkat: Vezessen be erős irányítási keretrendszert vállalati szintű Harmadik felekre és beszállítói biztonságra vonatkozó szabályzatunkkal, valamint annak KKV-k számára készült megfelelőjével.
• Kövesse a Zenith Blueprintet: Használja a Zenith Blueprint: auditori 30 lépéses ütemtervet egy megfelelő IBIR bevezetéséhez és auditálásához, külön lépésekkel a beszállítói kockázat magabiztos kezelésére.
• Használja ki a Zenith Controls előnyeit: Kérjen demót a Zenith Controls: több megfelelési keretrendszert összekapcsoló útmutatóból, hogy a beszállítói kontrollokat NIS2, DORA, GDPR, NIST és további követelményekhez rendelje, és auditterve átfogó, valamint védhető legyen.