Beépített biztonság az IKT-projektirányításban 2026-ban

A projekt határidőre elkészült, amíg az audit fel nem tett egy kérdést

Egy gyorsan növekvő fizetéstechnológiai vállalat CISO-ja jó hírekkel érkezett az igazgatóság elé. Az új ügyfélbeléptetési platform készen állt az éles üzembe állásra. A termékcsapat elkészítette a mobil felhasználói élményt, a mérnöki csapat integrálta a digitális személyazonosság-ellenőrzést, a jogi csapat aláírta a felhő- és API-szolgáltatókkal kötött megállapodásokat, az üzemeltetés pedig begyakorolta az élesítési tervet.

Ekkor a belső auditor feltett egy egyszerű kérdést:

„Mutassák meg, a projekt mely szakaszaiban vették figyelembe a biztonsági és adatvédelmi szempontokat.”

A projektszobában csend lett.

Volt penetrációs tesztjelentés, de későn készült. Volt felhőarchitektúra-diagram, de nem volt bizonyíték arra, hogy az adatáramlásokat a GDPR alapelvei szerint felülvizsgálták volna. Volt beszállítói átvilágítási kérdőív, de nem kapcsolták a kockázati nyilvántartáshoz. Volt változtatási jegy az éles bevezetéshez, de a jóváhagyás nem tért ki a kritikus szolgáltatásokra gyakorolt hatásra, az incidensjelentésre, a rezilienciatesztelésre, az ügyfélértesítésre vagy a személyesadat-sértés eszkalációjára. Voltak sprintjegyzetek, de a biztonsági követelmények felhasználói történetekben és chatüzenetekben szétszórva szerepeltek.

Semmi sem tűnt nyilvánvalóan gondatlannak. Minden egy mozgalmas, modern IKT-projekt képét mutatta. Egy DORA hatálya alá tartozó pénzügyi szervezet, egy potenciálisan NIS2 hatálya alá tartozó SaaS-szolgáltató, illetve egy GDPR szerinti adatkezelő vagy adatfeldolgozó számára azonban a kérdés már nem csak az, hogy volt-e biztonság. A kérdés az, hogy a beépített biztonság bizonyítható-e.

Ez a 2026-os kihívás. Az IKT-projekteket már nem csak a szállítási sebesség, a költségkontroll és a műszaki minőség alapján ítélik meg. Irányítási bizonyítékok alapján is értékelik őket: kockázatértékelések, tervezési döntések, beszállítói átvilágítás, biztonságos fejlesztési nyilvántartások, változásjóváhagyások, adatvédelmi döntések, teszteredmények és vezetői felügyelet alapján.

Az ISO/IEC 27001:2022 gyakorlati irányításirendszer-vázat ad a szervezeteknek e probléma kezeléséhez. Segít a CISO-knak, megfelelési vezetőknek, projektszponzoroknak, DPO-knak, architekteknek, beszerzési csapatoknak és auditoroknak abban, hogy a jelentős IKT-projekteket igazolható, beépített biztonsági bizonyítékká alakítsák.

Miért vált az IKT-projektirányítás szabályozási bizonyítékkérdéssé?

Egy felhőmigráció, ügyfélportál, fizetési platform, CRM-bevezetés, identitásszolgáltató-váltás, analitikai adatfolyam, API-integráció, SaaS-munkafolyamat, low-code alkalmazás vagy menedzselt szolgáltatásra való átállás mind megváltoztathatja a szervezet kockázati profilját. 2026-ban ezek a változások egymást átfedő kötelezettségek mellett történnek.

A NIS2 széles körben alkalmazandó az I. melléklet és a II. melléklet szerinti ágazatok alapvető és fontos szervezeteire, ideértve a digitális infrastruktúrát, a menedzselt szolgáltatókat, a menedzselt biztonsági szolgáltatókat és a digitális szolgáltatókat. A NIS2 Article 20 a vezető testületeket teszi felelőssé a kiberbiztonsági kockázatkezelési intézkedések jóváhagyásáért és végrehajtásuk felügyeletéért. A NIS2 Article 21 megfelelő és arányos műszaki, működési és szervezeti intézkedéseket követel meg a kockázatkezelés, az incidenskezelés, az üzletmenet-folytonosság, az ellátási lánc biztonsága, a biztonságos beszerzés, a biztonságos fejlesztés, a sérülékenységkezelés, az eredményesség értékelése, a kiberhigiénia, a kriptográfia, a hozzáférés-szabályozás, az eszközkezelés és a biztonságos kommunikáció területén.

A DORA a pénzügyi szervezetekre vonatkozik, és a digitális működési rezilienciára összpontosít. A DORA Article 5 az IKT-kockázatkezelésért való felelősséget a vezető testülethez rendeli. A DORA Article 6 megbízható, átfogó és megfelelően dokumentált IKT-kockázatkezelési keretrendszert követel meg. A DORA kiterjed az IKT-val kapcsolatos incidensek jelentésére, az operatív reziliencia tesztelésére, az IKT üzletmenet-folytonosságra, a reagálásra és helyreállításra, a kiberfenyegetettségi információk megosztására, az IKT harmadik fél kockázatkezelésére, a szerződéses megállapodásokra és a kritikus IKT harmadik fél szolgáltatók felügyeletére is.

A GDPR a személyes adatok tekintetében az elszámoltathatósági réteget adja hozzá. A GDPR Article 25 beépített és alapértelmezett adatvédelmet ír elő. Az adatkezelőknek képesnek kell lenniük igazolni az olyan alapelveknek való megfelelést, mint a jogszerűség, tisztességesség, átláthatóság, célhoz kötöttség, adattakarékosság, tárolási korlátozás, integritás, bizalmas jelleg és elszámoltathatóság. Ha az adatkezelés valószínűsíthetően magas kockázattal jár, a GDPR Article 35 szerinti adatvédelmi hatásvizsgálat is szükséges lehet.

A közös nevező a bizonyíték. A szabályozó hatóságok és az auditorok nem csak azt kérdezik, hogy egy platform titkosított, javított, vizsgált vagy tesztelt volt-e. Azt kérdezik, hogy a szervezet bizonyítani tudja-e: a biztonság, az adatvédelem, a beszállítói kockázat és a reziliencia kezdettől fogva része volt a döntéshozatalnak.

Ezért különösen erős az ISO/IEC 27001:2022 szerinti projektirányítás. Lehetővé teszi, hogy a szervezet a NIS2, DORA, GDPR, NIST CSF 2.0, szerződéses kötelezettségek és ügyfélbizonyossági igények kezelését egy ismételhető IBIR-folyamatban végezze, nem pedig több, egymástól elszakított ellenőrzőlistán keresztül.

Az ISO 27001 projektirányítási váza

Az ISO/IEC 27001:2022-t gyakran félreértik, és pusztán tanúsítási gyakorlatnak tekintik. IKT-projektek esetén a működési értéke ennél szélesebb: irányítási vázat ad az üzleti változásokhoz.

A 4.1–4.4 pontok megkövetelik, hogy a szervezetek megértsék a belső és külső tényezőket, az érdekelt feleket, a jogi, szabályozási és szerződéses követelményeket, az IBIR alkalmazási területét, az interfészeket és a függőségeket. Projektértelmezésben ez azt jelenti, hogy a projektalapító dokumentumnak azonosítania kell az érintett szolgáltatásokat, ügyfeleket, beszállítókat, szabályozásokat, üzleti folyamatokat, személyes adatokat, kritikus műveleteket és kiszervezett szolgáltatásokat.

Az 5.1–5.3 pontok vezetői elkötelezettséget, szabályzati összhangot, erőforrásokat, az üzleti folyamatokba való integrációt és kijelölt felelősségeket követelnek meg. Ez azért fontos, mert a NIS2 és a DORA egyaránt vezető testületi felelősség alá helyezi a kiberbiztonságot és az IKT-kockázatot. Egy kritikus ügyfélplatformot módosító projekt nem támaszkodhat egy chatben elhangzott informális biztonsági megjegyzésre. Egyértelmű elszámoltathatóságra van szüksége.

A 6.1.1–6.1.3 pontok ismételhető kockázatértékelési és kockázatkezelési folyamatot, kockázati kritériumokat, kockázattulajdonosokat, a bizalmasság, sértetlenség és rendelkezésre állás értékelését, kockázatkezelési terveket, alkalmazhatósági nyilatkozatot és maradványkockázat-jóváhagyást követelnek meg. Itt válik a projektkockázat auditbizonyítékká.

A 7.1–7.5 pontok erőforrásokat, kompetenciát, tudatosságot, kommunikációt és a dokumentált információk kezelését követelik meg. Így válnak a projektnyilvántartások megbízható bizonyítékká, nem pedig szétszórt artefaktumokká.

A 8.1 pont működéstervezést és -szabályozást, a folyamatok tervezett végrehajtását igazoló dokumentált információkat, a tervezett változások szabályozását, a nem szándékolt változások felülvizsgálatát, a kedvezőtlen hatások csökkentését, valamint az IBIR szempontjából releváns, külsőleg biztosított folyamatok, termékek vagy szolgáltatások kontrollját követeli meg. A 8.2 és 8.3 pontok információbiztonsági kockázatértékelést és kockázatkezelést írnak elő tervezett időközönként vagy jelentős változások esetén.

Az A melléklet ezt az irányítási ciklust gyakorlati kontrollokhoz kapcsolja. Az IKT-projektek beépített biztonsága szempontjából három ISO/IEC 27001:2022 A melléklet szerinti kontroll központi jelentőségű:

A Clarysec Zenith Blueprint: Egy auditor 30 lépéses ütemterve az információbiztonságot a projektmenedzsmentben valamennyi projekttípusra kiterjedő irányítási kérdésként kezeli, nem csak szoftverfejlesztési témaként:

„Bármely projekt – marketingrendszer-migráció, épületköltöztetés, üzleti folyamat újratervezése, HR beléptetési platform, sőt akár egy összeolvadás vagy felvásárlás – hatással lehet az információk bizalmasságára, sértetlenségére vagy rendelkezésre állására. Ha pedig hatással van, a biztonságnak helyet kell kapnia az asztalnál.”

Ugyanez a szakasz rögzíti a megvalósítás fő tanulságát:

„Ennek a kontrollnak nem az a célja, hogy bürokráciával terhelje a projekteket. Az a célja, hogy a biztonság tervezési bemenetként jelenjen meg, ne pedig tesztelési fázisként.”

Ez a különbség választja el a megfelelési látszattevékenységet az igazolható, beépített biztonságtól.

Hogyan néz ki a beépített biztonság egy IKT-projektben?

A beépített biztonság az első sprint, beszerzési igény, architektúra-diagram vagy migrációs helyreállítási forgatókönyv előtt kezdődik. Egy egyszerű kérdést tesz fel: mit változtathat ez a projekt a kockázatokon?

Egy gyakorlati projektirányítási modell hét bizonyítékkaput használ.

A cél nem a bürokrácia. A cél az, hogy a biztonság látható legyen ott, ahol a projekt döntései ténylegesen megszületnek.

A Clarysec Enterprise Információbiztonsági szabályzat ezt közvetlenül így fogalmazza meg:

„A biztonsági irányítást integrálni kell a vállalatirányítással, a projektmenedzsmenttel, a beszerzéssel és a jogi felügyeleti funkciókkal annak biztosítása érdekében, hogy az információbiztonság ne elszigetelten működjön, hanem az üzleti döntéshozatal teljes folyamatába beépüljön.”

Az „Irányítási követelmények” szakasz 5.5 szabályzati pontjából.

A projekt-életciklusokat is végrehajtási kérdéssé teszi:

„Projekt-életciklusok (pl. biztonságos fejlesztés, fenyegetésmodellezés)”

„A szabályzat végrehajtásának követelményei” szakasz 6.3.1.1 szabályzati pontjából.

És rögzíti azt az auditálási alapelvet, amelyet sok szervezet túl későn ismer fel:

„Minden bevezetett kontrollnak auditozhatónak kell lennie, dokumentált eljárásokkal és a működés megőrzött bizonyítékaival alátámasztva.”

„A szabályzat végrehajtásának követelményei” szakasz 6.6.1 szabályzati pontjából.

Más szóval: a nem irányított, nem megőrzött és nem leképezett biztonsági munka gyakran akkor is elbukik az auditon, ha a műszaki csapatok észszerű döntéseket hoztak.

A fenyegetésmodellezéstől a bizonyítékig: gyakorlati fintech példa

Vegyünk egy projektet, amelynek célja egy új EU-s ügyfélbeléptetési portál elindítása egy fintech számára. A portál személyazonosító dokumentumokat gyűjt, harmadik féllel biometrikus ellenőrzést végez, tárolja a beléptetési státuszt, integrálódik a CRM-mel, ügyfélértesítéseket indít, és kockázati pontozást táplál.

A beépített biztonsági megközelítés a projekt előrehaladásával együtt építi fel a bizonyítékokat.

Először meg kell nyitni a projektbiztonsági besorolási nyilvántartást. Azonosítani kell, hogy a projekt érint-e kritikus vagy fontos funkciókat, személyes adatokat, a személyes adatok különleges kategóriáit, hitelesítést, ügyféloldali rendelkezésre állást, kiszervezett IKT-szolgáltatásokat, szabályozott jelentéstételi folyamatokat vagy ügyfélkommunikációt. A GDPR alapján az egyedi azonosításra használt biometrikus adat a személyes adatok különleges kategóriájának minősül, kivéve, ha konkrét kivétel alkalmazható. Ez azonnal magasabb szintű jogi elemzést és védelmi intézkedéseket követel meg.

Másodszor projektkockázatértékelést kell készíteni. A Clarysec SME Kockázatkezelési szabályzat a kockázatkezelést a tervezés részévé teszi, nem negyedéves táblázatkitöltéssé:

„1.2 Biztosítja, hogy a kockázatkezelés a tervezés, a projektvégrehajtás, a beszállító-kiválasztás és az incidensreagálás aktív eleme legyen, összhangban az ISO 27001, ISO 31000 és az alkalmazandó szabályozási követelményekkel.”

A „Cél” szakasz 1.2 szabályzati pontjából.

Vállalati környezetekben a Clarysec Enterprise Kockázatkezelési szabályzat a hatókört stratégiai, projekt- és műszaki szinteken is meghatározza:

„Kiterjed a stratégiai, működési, projekt- és műszaki szintű információbiztonsági kockázatokra, és kötelező minden olyan munkatárs, vállalkozó és szolgáltató számára, aki vagy amely az információbiztonsági irányítási rendszer (ISMS) tevékenységeiben részt vesz.”

A „Hatály” szakasz 2.3 szabályzati pontjából.

Harmadszor, a fejlesztés megkezdése előtt fenyegetésmodellt kell készíteni. Az Enterprise Biztonságos fejlesztési szabályzat egyértelmű:

„Minden új alkalmazásnak és jelentős változásnak biztonsági architektúra-felülvizsgálaton és fenyegetésmodellezésen kell átesnie a fejlesztés megkezdése előtt.”

„A szabályzat végrehajtásának követelményei” szakasz 6.1.1 szabályzati pontjából.

Az ügyfélbeléptetési portál esetén a fenyegetésmodellnek ki kell terjednie a kitett interfészekre, az identitásfolyamatokra, a jogosultsági határokra, az API-visszaélési esetekre, a webhook-hamisításra, a visszajátszásos támadásokra, a kompromittálódott hitelesítő adatokra, az adatszivárgási útvonalakra, a függőségi kockázatra, a naplózási követelményekre, a biztonsági mentési feltételezésekre, a helyreállítási követelményekre és a szolgáltatói hibamódokra.

Negyedszer frissíteni kell az adatvédelmi bizonyítékokat. Az SME Adatvédelmi és magánszféra-védelmi szabályzat meghatározza az alapkövetelményt:

„5.3.1. A beépített és alapértelmezett adatvédelmet minden új rendszerben és szolgáltatásban érvényesíteni kell”

Az „Irányítási követelmények” szakasz 5.3.1 szabályzati pontjából.

A projektnyilvántartásnak tartalmaznia kell a célt, a jogalapot, az adatkezelői vagy adatfeldolgozói szerepkört, az adattakarékossági döntéseket, a megőrzési szabályokat, a hozzáférési szerepköröket, a titkosítási döntéseket, az érintettekre gyakorolt hatások megfontolását, az átláthatósági követelményeket, az adatfeldolgozói feltételeket és a személyesadat-sértés bejelentési útvonalait.

Ötödször rögzíteni kell a biztonságos fejlesztési bizonyítékokat. Az SME Biztonságos fejlesztési szabályzat tömör bizonyítéklistát ad, amely kis- és középvállalati csapatoknál is működik:

„5.3 Az ügyvezetőnek (GM) nyilvántartást kell vezetnie a következőkről: 5.3.1 Minden aktív szoftverfejlesztési projekt és a felelős fejlesztők vagy beszállítók 5.3.2 Az egyes projektekhez használt biztonsági ellenőrzőlisták 5.3.3 Az elvégzett kód-felülvizsgálatok és az azokat végző személyek 5.3.4 A bevezetést megelőző teszteredmények 5.3.5 Harmadik féltől származó komponensek és azok kapcsolódó licenc- vagy kockázati státusza”

Az „Irányítási követelmények” szakasz 5.3 szabályzati pontjából.

Hatodszor, a bevezetést változásként kell kezelni. Az SME Változáskezelési szabályzat így rendelkezik:

„1.1 Ez a szabályzat biztosítja, hogy az IT-rendszerek, konfigurációk, üzleti alkalmazások vagy felhőszolgáltatások minden változtatása tervezett, kockázatértékelt, tesztelt és a végrehajtás előtt jóváhagyott legyen.”

A „Cél” szakasz 1.1 szabályzati pontjából.

Az ügyfélbeléptetési portál esetén a változtatási jegynek tartalmaznia kell az érintett szolgáltatásokat, a kockázatértékelést, a teszteredményeket, a visszaállítási tervet, a monitorozási tervet, a biztonsági jóváhagyásokat, az adatvédelmi jóváhagyást, a beszállítói felkészültséget, az incidens-eszkalációs frissítéseket és az ügyfélkommunikációs kiváltó eseményeket.

Végül le kell képezni a kötelezettségeket. Az SME Jogi és szabályozói megfelelési szabályzat meghatározza a működési szabályt:

„5.2.2 Ha egy szabályozás több területre is alkalmazandó (pl. a GDPR a megőrzésre, a biztonságra és az adatvédelemre), ezt egyértelműen le kell képezni a Megfelelőségi nyilvántartásban és a képzési anyagokban.”

Az „Irányítási követelmények” szakasz 5.2.2 szabályzati pontjából.

Ez a Megfelelőségi nyilvántartás lesz a híd az ISO/IEC 27001:2022 kontrollok, a NIS2 Article 21 intézkedések, a DORA IKT-kockázati kötelezettségek, a GDPR szerinti elszámoltathatóság és az ügyfélszerződéses vállalások között.

Egy projekt bizonyítékcsomagjának leképezése NIS2, DORA, GDPR és NIST CSF 2.0 szerint

A leghatékonyabb megfelelési stratégia nem a munka megkettőzése. Hanem egy erős bizonyítékkészlet több kötelezettséghez történő leképezése.

A Zenith Blueprint a kockázatkezelési fázis 14. lépésében ilyen típusú kereszthivatkozási munkát javasol:

„Minden alkalmazandó szabályozáshoz létrehozhat egy egyszerű leképezési táblázatot (akár egy jelentés mellékleteként), amely felsorolja a szabályozás fő biztonsági követelményeit és az IBIR-ben szereplő megfelelő kontrollokat/szabályzatokat.”

Hozzáteszi, hogy ez azért hasznos, mert megmutatja az auditoroknak és értékelőknek, „hogy a biztonságot nem légüres térben kezeli, hanem ismeri a jogi kontextust”.

A Clarysec Zenith Controls: Keresztmegfelelési útmutató ugyanezt az integrált megközelítést támogatja azzal, hogy az ISO/IEC 27001:2022 kontrollokat más keretrendszerekhez, audit elvárásokhoz és megfelelési igényekhez térképezi. Az IKT-projektirányításban az A.5.8, A.8.25 és A.8.32 kontrollokat megelőző kontrollként kezeli, amelyek a bizalmasságot, sértetlenséget és rendelkezésre állást védik az irányítás, az alkalmazásbiztonság, az ökoszisztéma, a védelem, valamint a rendszer- és hálózatbiztonsági szempontok mentén.

Ez a táblázat nem helyettesíti a jogi elemzést. Irányítási gyorsító. Biztosítja, hogy a CISO, a DPO, a projektszponzor, a beszerzési vezető, a rendszergazda és a belső auditor ugyanazokat a bizonyítékokat nézze.

A NIST CSF 2.0 is természetesen illeszkedik ehhez a modellhez. GOVERN funkciója segít a szervezeteknek a szabályzatok, szerepkörök, kockázatvállalási hajlandóság, felügyelet, valamint jogi vagy szerződéses tudatosság kialakításában. IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER funkciói közös működési nyelvet adnak a csapatoknak az eszközök, beszállítói szolgáltatások, hozzáférés-szabályozás, adatbiztonság, platformbiztonság, biztonságos szoftverfejlesztés, monitorozás, incidensreagálás és helyreállítás megvitatásához.

Egyetlen, ISO 27001-gyel összhangban álló, az A melléklet A.5.8 kontrolljára épülő folyamat igazolható bizonyítékot tud előállítani mindezen elvárásokhoz.

A biztonságos fejlesztés több, mint kódírás

Sok IKT-projekt azért vall kudarcot, mert a szervezet a biztonságos fejlesztést kizárólag fejlesztői feladatnak tekinti. 2026-ban a biztonságos fejlesztés magában foglalja a SaaS-konfigurációt, a munkafolyamat-automatizálást, az infrastruktúra mint kód megoldásokat, az API-integrációkat, az identitásszabályokat, a felhő landing zone-okat, az analitikai adatfolyamokat, a robotizált folyamatautomatizálást és a low-code üzleti alkalmazásokat is.

A Zenith Blueprint a „Kontrollok működésben” fázis 20. lépésében az ISO/IEC 27002:2022 8.25 Biztonságos fejlesztési életciklus kontrollját tárgyalja:

„Ez a kontroll akkor is alkalmazandó, ha saját alkalmazásokat ír, ERP- vagy CRM-rendszerekhez hasonló platformokat konfigurál, SaaS-munkafolyamatokat testreszab, vagy infrastruktúra mint kód környezeteket kezel.”

Azt is kifejti, hogy a biztonsági követelményeknek a funkcionális követelmények mellett kell szerepelniük, és hogy a fenyegetésmodellezés segít azonosítani a rendszer kitett részeit, a kockázatos felhasználói szerepköröket és a magasabb védelmet igénylő adatáramlásokat.

Egy modern projektben a biztonságos fejlesztési bizonyítékok a következőket tartalmazhatják:

• Üzleti követelményekhez kapcsolt biztonsági követelmények
• Fenyegetésmodell vagy biztonsági architektúra-felülvizsgálat
• Biztonságos kódolási vagy biztonságos konfigurációs ellenőrzőlista
• Kód-felülvizsgálati vagy társfelülvizsgálati bejegyzések
• Komponensleltár és függőségi kockázati státusz
• Titokkezelési döntések
• Hozzáférés-szabályozási és legkisebb jogosultság elve szerinti tervezés
• Naplózási és monitorozási követelmények
• Sérülékenységvizsgálati eredmények és helyesbítő intézkedési bejegyzések
• Előéles biztonsági tesztelés
• Ahol releváns, biztonsági mentési, helyreállítási és rezilienciatesztelés
• Bevezetési jóváhagyás és visszaállítási bizonyítékok

A cél nem az, hogy minden projektet ugyanazon nehézsúlyú folyamaton kényszerítsünk át. A cél az arányosság. Egy kisebb belső munkafolyamat-változás nem igényel ugyanolyan bizonyítékot, mint egy alapvető fizetési platform migrációja. De minden projektet be kell sorolni, kockázatértékelni kell, és a hatása szerint kell irányítani.

A változáskezelés megvédi a projektet saját magától

Sok projektben a legkockázatosabb pillanat nem a tervezés vagy a kódolás. Hanem a bevezetés.

Egy csapat elvégezheti a fenyegetésmodellezést, a kód-felülvizsgálatot, a beszállítói értékelést és az adatvédelmi felülvizsgálatot, majd egy siettetett éles változtatással mégis kiesést vagy adatsértést okozhat. Bekapcsolva marad egy hibakeresési jelző. Egy tűzfalszabály tágabb a jóváhagyottnál. Egy migrációs szkript személyes adatokat másol egy nem éles környezetbe. Egy harmadik fél webhook-végpont hitelesítés nélkül kerül bevezetésre. Egy naplózási változás személyazonosító okmányok számait rögzíti. Egy biztonsági mentési feladat a cutover után csendben meghibásodik.

A Zenith Blueprint a „Kontrollok működésben” fázis 21. lépésében közvetlenül írja le az ISO/IEC 27002:2022 8.32 Változáskezelés kontrollját:

„A változás elkerülhetetlen, de a kiberbiztonságban a kontrollálatlan változás veszélyes.”

Majd így folytatja:

„Lényegét tekintve a hatékony változáskezelés ismételhető munkafolyamat. Egy világos javaslattal kezdődik, amely meghatározza, mi változik, miért, mikor, és melyek a lehetséges kockázatok.”

Egy erős IKT-változásbejegyzésnek meg kell válaszolnia a következőket:

• Mely rendszer, szolgáltatás, adatáramlás, beszállító vagy konfiguráció változik?
• Mely kockázatokat azonosították, és kik a tulajdonosaik?
• Érinti-e a változás a személyes adatokat, kritikus szolgáltatásokat, hitelesítést, naplózást, biztonsági mentéseket vagy incidensreagálást?
• Milyen biztonsági, adatvédelmi, reziliencia- és beszállítói ellenőrzéseket végeztek el?
• Milyen teszteket zártak le a bevezetés előtt?
• Milyen monitorozás igazolja majd az elvárt működést?
• Milyen visszaállítási vagy helyreállítási terv áll rendelkezésre?
• Ki hagyta jóvá a maradványkockázatot?
• Milyen bizonyítékokat kell megőrizni?

A DORA esetében ez támogatja a dokumentált IKT-kockázatkezelést, a rezilienciát, a folytonosságot, az incidensosztályozást és a tanulságok feldolgozását. A NIS2 esetében támogatja a kockázatkezelési intézkedéseket, a biztonságos fejlesztést, az incidensek megelőzését és a folytonosságot. A GDPR esetében segít igazolni, hogy a személyes adatokat érintő változásokat a célhoz kötöttség, az adattakarékosság, a megőrzés, a hozzáférés és a biztonság alapelvei szerint vizsgálták felül.

A beszállítói és felhődöntéseknek a projekttervezés részét kell képezniük

A modern IKT-projektekben a legnagyobb kockázatú tervezési döntés gyakran a „vásárlás”, nem pedig az „építés”. A felhőszolgáltatások, API-szolgáltatók, identitásellenőrzési platformok, fizetési szolgáltatók, analitikai beszállítók, menedzselt szolgáltatók és menedzselt biztonsági szolgáltatók a kockázati felület részévé válnak.

A NIS2 kifejezetten magában foglalja az ellátási lánc biztonságát, a közvetlen beszállítók és szolgáltatók sérülékenységeit, a beszállítói kiberbiztonsági gyakorlatokat, a biztonságos fejlesztési eljárásokat és a koordinált ellátásilánc-kockázatértékelések eredményeit. A DORA pénzügyi szervezetek esetében ennél mélyebbre megy. Az IKT-kockázatkezelési keretrendszer részeként megköveteli az IKT harmadik fél kockázatkezelését, a folyamatos felelősséget akkor is, ha az IKT-szolgáltatásokat kiszervezik, az információs nyilvántartásokat, a szerződéskötés előtti értékeléseket, a koncentrációs kockázat elemzését, a szerződéses kontrollokat, az audit- és vizsgálati jogokat, a megszüntetési kiváltó okokat, valamint a kritikus vagy fontos funkciókra vonatkozó tesztelt kilépési stratégiákat.

Az ügyfélbeléptetési portál esetén a biometrikus ellenőrzési szolgáltató nem hagyható jóvá pusztán azért, mert a beszerzés kedvezőnek találja az árat, az API-dokumentáció pedig megfelelő. A projektnek bizonyítékra van szüksége a biztonsági átvilágításról, az adatkezelési szerepkörről, az adatok helyéről, az alvállalkozókról, a rendelkezésre állási vállalásokról, az incidens-támogatásról, az auditálási jogokról, a megszüntetéskori segítségnyújtásról, a kilépés megvalósíthatóságáról és a monitorozási kötelezettségekről.

Egy érett bizonyítékmodellben a beszállítói és felhődöntések a projekt bizonyítékcsomagjában szerepelnek, nem egy különálló beszállítói mappában. Amikor az auditor megkérdezi, miért fogadtak el egy harmadik felet, a válasznak tartalmaznia kell az üzleti igényt, a kockázatértékelést, a szerződéses garanciákat, az adatvédelmi felülvizsgálatot, a rezilienciára gyakorolt hatást és a folyamatos monitorozást.

Hogyan vizsgálják az auditorok a beépített biztonság bizonyítékait?

A különböző auditorok ugyanazt az IKT-projektet eltérő nézőpontból közelítik meg. Egy tanúsítási auditor, belső auditor, DORA-felülvizsgáló, NIS2 illetékes hatóság, adatvédelmi auditor, NIST-orientált értékelő vagy COBIT-szemléletű auditor hasonló bizonyítékokat kérhet, de eltérően értelmezheti őket.

Az auditorok nem egy szép projektdiasort szeretnének látni. Visszakövethetőséget akarnak. Látni akarják, hogy a követelmények kockázatokhoz vezettek, a kockázatok kontrollokhoz, a kontrollok megvalósítási bizonyítékokhoz, a megvalósítás pedig felülvizsgálathoz.

Ezért hasznos a Zenith Controls az auditfelkészülésben. Segít a csapatoknak elmagyarázni, miért megelőző kontroll az A melléklet A.5.8, A.8.25 és A.8.32 kontrollja, amelyek a bizalmasságot, sértetlenséget és rendelkezésre állást védik, mielőtt az előre látható hibák elérnék az éles környezetet.

A minimális Clarysec projektbizonyíték-csomag

Egy erős, beépített biztonsági bizonyítékcsomagnak nem kell óriásinak lennie. Következetesnek, arányosnak és leképezettnek kell lennie.

Közepes kockázatú IKT-projekt esetén a Clarysec jellemzően az alábbi minimális csomagot javasolja:

1. Projektbiztonsági besorolási bejegyzés
2. Szabályozási alkalmazhatósági feljegyzés, amely lefedi a NIS2-t, ahol releváns a DORA-t, a GDPR-t és a szerződéses kötelezettségeket
3. Adatáramlási és eszközhatás-térkép
4. Projektkockázatértékelés és kockázatkezelési terv
5. Fenyegetésmodell vagy biztonsági architektúra-felülvizsgálat
6. Beszállítói és felhőszolgáltatási értékelés, ahol alkalmazandó
7. Biztonságos fejlesztési ellenőrzőlista vagy konfigurációs ellenőrzőlista
8. Biztonsági teszteredmények és helyesbítő intézkedési bizonyítékok
9. Változásjóváhagyás visszaállítási és monitorozási tervvel
10. Beépített adatvédelmi bejegyzés, személyes adatok érintettsége esetén jogalappal és megőrzéssel együtt
11. Incidensreagálási és monitorozási frissítések
12. Bevezetést követő felülvizsgálat és tanulságok
13. Megfelelőségi nyilvántartás leképezése kontrollokra és kötelezettségekre

A Zenith Blueprint adja az ütemtervi logikát. A 22. lépés az információbiztonságot valamennyi projektfázisba beemeli. A 20. lépés a biztonságos fejlesztést beépíti a tervezésbe, a designba, a kódba, a tesztelésbe és a bevezetésbe. A 21. lépés strukturálttá, visszakövethetővé és felülvizsgálhatóvá teszi a változáskezelést. A 14. lépés javasolja a GDPR, NIS2, DORA és más kötelezettségek kereszthivatkozását, hogy a megfelelési követelmények ne vesszenek el.

A szabályzatok működési szabályokat adnak. Az Információbiztonsági szabályzat integrálja a biztonságot a projektmenedzsmenttel, a beszerzéssel és a jogi felügyelettel. A Kockázatkezelési szabályzat az IBIR-tevékenység részévé teszi a projektkockázatokat. A Biztonságos fejlesztési szabályzat előírja a fenyegetésmodellezést. A Változáskezelési szabályzat tervezett, kockázatértékelt, tesztelt és jóváhagyott változásokat követel meg. Az Adatvédelmi és magánszféra-védelmi szabályzat beépített és alapértelmezett adatvédelmet ír elő. A Jogi és szabályozói megfelelési szabályzat megköveteli, hogy a több területre kiterjedő szabályozásokat le kell képezni a Megfelelőségi nyilvántartásban.

Ezek az eszközök együtt a beépített biztonságot törekvésből auditozható működési modellé alakítják.

Gyakori hibaminták IKT-projektekben

A hibák általában előre láthatók.

Az első a biztonság késői bevonása. A biztonsági felülvizsgálatok azután történnek, hogy az architektúra rögzült, a szerződéseket aláírták, és a szállítási dátumok nyilvánossá váltak. Ekkor a biztonság tervezési bemenet helyett akadállyá válik.

A második a széttagolt bizonyíték. A projekt teszteredményei az egyik eszközben, a beszállítói felülvizsgálat egy másikban, az adatvédelmi megjegyzések e-mailben, a kockázatelfogadás egy értekezletfelvételen, a változásjóváhagyás pedig egy jegyben található. Egyetlen összefüggő szál sem bizonyítja az irányítást.

A harmadik a beszállítói vakfoltok jelenléte. A projekt felhőszolgáltatásra vagy API-szolgáltatóra támaszkodik, de senki sem ellenőrzi az alvállalkozókat, az adatok helyét, az auditálási jogokat, az incidens-támogatást, a kilépési terveket vagy a koncentrációs kockázatot.

A negyedik az adatvédelmi sodródás. Egy adott célra épített rendszer analitikát, AI-kísérletezést, marketingexportot vagy operatív monitorozást kezd támogatni anélkül, hogy újra megvizsgálnák a jogalapot, az átláthatóságot, az adattakarékosságot vagy a megőrzést.

Az ötödik a felülvizsgálat nélküli változás. Egy éles bevezetést funkcionalitás alapján jóváhagynak, de nem értékelik hozzáférés, naplózás, titkosítás, biztonsági mentés, reziliencia, személyes adatok vagy jelentéstételi hatás szempontjából.

A hatodik a gyenge vezetői felügyelet. A nagy hatású projektkockázatokat túl alacsony szinten fogadják el, és nincs bizonyíték arra, hogy a felelős kockázattulajdonos megértette volna a szabályozási következményeket.

Ezeket a problémákat nem oldja meg egy újabb vizsgálóeszköz megvásárlása. Úgy oldhatók meg, ha a biztonsági irányítás beépül abba, ahogyan a projekteket javasolják, megtervezik, beszerzik, kialakítják, tesztelik, változtatják és felülvizsgálják.

A 2026-os CISO tanulsága

Az IKT-projektekben alkalmazott beépített biztonság ma már igazgatósági, audit- és szabályozási kérdés. A NIS2 a kiberbiztonsági kockázatkezelést vezető testületi üggyé teszi. A DORA az IKT-kockázatot, a rezilienciatesztelést, az incidenskezelést és a harmadik felek felügyeletét strukturált pénzügyi szektorbeli kötelezettséggé teszi. A GDPR elszámoltathatóságot követel meg a személyes adatok kezelése és a megfelelő biztonság tekintetében. Az ISO/IEC 27001:2022 biztosítja azt az irányításirendszer-struktúrát, amely e kötelezettségeket működésbe ülteti.

A CISO-k számára a lehetőség az, hogy ne a szállítás végén kelljen harcolni a projektcsapatokkal. A biztonságot a projektindításba, a követelményekbe, a tervezésbe, a beszállító-kiválasztásba, a kialakításba, a tesztelésbe, a változásjóváhagyásba és a bevezetést követő felülvizsgálatba kell beépíteni.

A megfelelési vezetők számára a lehetőség az, hogy a szétszórt bizonyítékokat egyetlen leképezett projektbizonyíték-csomaggal váltsák fel.

Az auditorok számára a lehetőség az, hogy a projekt-életciklust vizsgálják, ne csak a végső rendszert.

Az üzleti felelősök számára a lehetőség a gyorsabb és biztonságosabb szállítás. A beépített biztonság csökkenti az újramunkát, megelőzi a megfelelési meglepetéseket, javítja a beszállítói döntéseket, és igazolható kockázati történetet ad a vezetésnek.

Ha az IKT-projektjei gyorsabban haladnak, mint a bizonyítékmodellje, kezdjen egy pilot projekttel. Használja a Clarysec Zenith Blueprint útmutatót a projektbiztonsági kapuk meghatározásához, alkalmazza a Clarysec kockázatkezelési, biztonságos fejlesztési, változáskezelési és adatvédelmi szabályzatait, és használja a Zenith Controls megoldást az ISO/IEC 27001:2022 projektirányítás NIS2, DORA, GDPR és NIST CSF 2.0 szerinti leképezéséhez.

A Clarysec segíthet újrahasznosítható, beépített biztonságot alkalmazó projektbizonyíték-csomag kialakításában, annak IBIR-rel való összehangolásában, valamint belső auditra, tanúsítási auditra, DORA-felkészültségre, NIS2-irányításra és GDPR szerinti elszámoltathatóságra történő előkészítésében.

Kezdje a következő jelentős IKT-projektjével. Ha rendszereket, beszállítókat, adatokat, hozzáférést, rezilienciát vagy ügyfélbizalmat változtat meg, az első naptól megérdemli a beépített biztonságot.