Secure-by-demand szoftverbeszerzés 2026-ban

2026 elején, egy kedd reggelen Maria, egy gyorsan növekvő európai fizetési vállalat CISO-ja, az igazgatóságnak tart előadást. Az utolsó napirendi pontnak rutinszerűnek kellene lennie: egy új, mesterséges intelligenciával támogatott csalásfelderítési platform jóváhagyása. A beszállítónak meggyőző demója, korlátozott ideig érvényes kedvezménye, egyoldalas biztonsági áttekintése és sztenderd szerződése van.

Ekkor elkezdődnek a kérdések.

A vezérigazgató megkérdezi: „Honnan tudjuk, hogy ez a platform biztonságos? Pénzügyi szolgáltatási ügyfeleink DORA-megfelelési bizonyítékokat kérnek, és ez a beszállító a kritikus infrastruktúránk részévé válik.”

A jogi terület azt kérdezi, készen áll-e az adatfeldolgozási szerződés, hol kezelik majd az EU-s ügyféladatokat, és közzétették-e a további adatfeldolgozókat. Az operatív rezilienciáért felelős vezető a kilépési tervezésről, a biztonsági mentések exportjáról és a kritikus funkciók folytonosságáról kérdez. A termékbiztonsági mérnök sérülékenység-feltárást, javításkezelési bizonyítékokat és SBOM-ot vagy azzal egyenértékű komponensátláthatósági nyilatkozatot kér. A beszerzés felteszi azt a kérdést, amely igazán költségessé teszi a beszállítói kockázatot: „Jóváhagyhatjuk most, és összegyűjthetjük a dokumentumokat az aláírás után?”

Ez az a pillanat, amikor a modern szoftverbeszerzés vagy kontrollá válik, vagy egy jövőbeli incidensjelentés alapanyagává.

2026-ban a biztonságos szoftverbeszerzés nem támaszkodhat a szerződéskötés utáni jóindulatra. A NIS2 ellátásilánc-biztonsága, a DORA IKT harmadik felekkel kapcsolatos kockázata, a GDPR szerinti adatfeldolgozói elszámoltathatóság és a Cyber Resilience Act termékbiztonsági elvárásai a beszállítói bizonyosságot a beszerzési döntési pontra helyezték. A vevőknek secure-by-demand szoftverbeszerzésre van szükségük, ahol az ügyfél a vásárlás előtt meghatározza a biztonsági bizonyítékokat, a szerződéses záradékokat, a bevezetési kapukat és az operatív felelősségeket.

A Clarysec ügyfelei számára a válasz nem egy újabb táblázat, amely e-mailben elhal. A válasz egy ISO/IEC 27001:2022-vel összhangban álló beszerzési kontrollrendszer, amely Clarysec szabályzatokra, a Zenith Blueprint: egy auditor 30 lépéses ütemterve anyagra és a Zenith Controls rendszerre épül, hogy minden szoftver- vagy SaaS-beszerzésnek igazolható nyomvonala legyen az üzleti igénytől a beszállítói kockázati döntésig.

A secure-by-demand az új szoftverbeszerzési kontroll

A secure-by-design megközelítést általában beszállítói oldalról tárgyalják. A secure-by-demand vevőoldali fegyelem: a szervezet nem vásárol szoftvert, ha a beszállító nem tudja igazolni, hogy a biztonság, az adatvédelem, a reziliencia, a sérülékenységkezelés és az ellenőrizhetőség beépült az ajánlatba.

Ez megváltoztatja a beszerzési párbeszédet. Ahelyett, hogy a beszerzés azt kérdezné: „Van biztonságuk?”, pontosabb kérdéseket tesz fel:

• Milyen adatokat fog kezelni, hol és milyen jogi szerepben?
• Mely üzleti funkció függ majd Öntől, és mennyire kritikus ez a funkció?
• Milyen bizonyíték igazolja, hogy a kontrolljai működnek, nem csak dokumentáltak?
• Milyen incidensbejelentési határidőket vállal?
• Milyen sérülékenység-feltárási, javításkezelési, SBOM- vagy VEX-bizonyítékot tud benyújtani?
• Mely alvállalkozók vagy további adatfeldolgozók férnek hozzá az adatainkhoz vagy a szolgáltatásunkhoz?
• Tudunk-e auditálni, vizsgálatot végezni vagy bizonyítékot kérni a szerződés időtartama alatt?
• Mi történik megszüntetés, migráció, incidens, fizetésképtelenség vagy szabályozó hatósági megkeresés esetén?

Az ISO/IEC 27001:2022 biztosítja ennek az elmozdulásnak az irányítási rendszerbeli gerincét. A 4. fejezet megköveteli, hogy a szervezet megértse a környezetét, az érdekelt feleket és az IBIR alkalmazási területét, beleértve a külső szabályozási és beszállítói követelményeket. Az 5. fejezet a beszállítói kockázatot vezetői és irányítási felelősséggé teszi. A 6. fejezet kockázatértékelést, kockázatkezelést, kontrollkiválasztást, alkalmazhatósági nyilatkozatot és maradványkockázati döntéseket ír elő. A 8. fejezet a folyamatok szabályozott működtetését követeli meg, beleértve a külső felek által biztosított folyamatokat is. A 9. fejezet monitorozást, belső auditot és vezetőségi átvizsgálást ír elő.

Ez azt jelenti, hogy a szoftverbeszerzés nem pusztán kereskedelmi munkafolyamat. Működtetett és auditálható IBIR-folyamattá válik. A szabályozó hatóságok és auditorok egyre gyakrabban kérdezik meg, miért fogadott el egy szervezet egy beszállítót azelőtt, hogy megértette volna a kockázatot. A secure-by-demand beszerzés világos választ ad: a kockázatot felmérték, kezelték, szerződésben szabályozták és felelőshöz rendelték, mielőtt a függőség létrejött.

Miért találkozik a NIS2, a DORA, a GDPR és a CRA a beszállító kiválasztásánál

Maria igazgatósága a megfelelő kérdéseket teszi fel, mert egyetlen szoftverbeszállító egyszerre több kötelezettséget is aktiválhat.

A NIS2 ágazat, méret és kritikus jelleg alapján alkalmazandó; az Annex I és Annex II számos digitális, pénzügyi, infrastrukturális, menedzselt szolgáltatási és felhőfüggő szervezetet von hatály alá. Az Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő, beleértve az ellátásilánc-biztonságot, a biztonságos beszerzést, a biztonságos fejlesztést és karbantartást, a sérülékenységkezelést, a hozzáférés-szabályozást, az eszközkezelést, a folytonosságot, az incidenskezelést és a kontrollhatékonyság értékelését. Az Article 21(3) kifejezetten megköveteli a közvetlen beszállítók sérülékenységeire és a beszállítók kiberbiztonsági gyakorlatára fordított figyelmet. Az Article 23 szakaszos jelentősincidens-jelentési elvárásokat hoz létre, beleértve a 24 órán belüli korai figyelmeztetést és a 72 órán belüli bejelentést.

A DORA 2025. január 17-től alkalmazandó a hatálya alá tartozó pénzügyi szervezetekre. Egységes követelményeket állapít meg az IKT-kockázatkezelésre, az IKT-vonatkozású incidensjelentésre, a digitális működési reziliencia tesztelésére és az IKT harmadik felekkel kapcsolatos kockázatkezelésre. A DORA különösen előíró jellegű a beszerzés tekintetében. A pénzügyi szervezeteknek IKT harmadik felekkel kapcsolatos kockázati stratégiára, az IKT-szolgáltatási megállapodások nyilvántartására, kellő gondossági vizsgálatra, koncentrációs kockázatelemzésre, biztonsági és rezilienciakövetelményeket tartalmazó írásbeli szerződésekre, auditálási jogokra és hozzáférési jogokra, együttműködési kötelezettségekre, megszüntetési jogokra és kilépési tervekre van szükségük. Az Articles 28 és 30 központi jelentőségű az IKT harmadik felekkel kapcsolatos kockázat és a szerződéses kontrollok szempontjából, míg az Articles 17 to 23 az incidenskezelést és jelentéstételt alakítja.

A GDPR hozzáadja az adatfeldolgozói elszámoltathatósági kaput. Az Articles 5, 28, 32, 33 és 34 elszámoltathatóságot, adatfeldolgozói szerződéseket, megfelelő biztonságot, adatsértés-bejelentési együttműködést és az érintettekre gyakorolt hatások kezelését írják elő. Az a SaaS-beszállító, amely személyes adatokat kezel, nem pusztán beszállító. Az adatkezelő megfelelési helyzetének részévé válik. A DPA-t, a technikai és szervezési intézkedéseket, a további adatfeldolgozók listáját, az adattovábbítási garanciákat, a megőrzési szabályokat és a törlési kötelezettségeket még az adatkezelés megkezdése előtt meg kell érteni.

A CRA elvárások termékbizonyosságot adnak hozzá. Még ha a vevő nem is gyártó, a beszerzési csapatoknak bizonyítékot kell kérniük a biztonságos fejlesztésről, a sérülékenységkezelésről, a terméktámogatásról, a biztonsági frissítésekről, a koordinált sérülékenység-feltárásról és a komponensátláthatóságról, például SBOM-ról vagy egyenértékű nyilatkozatról. Ezeknek a követelményeknek helyük van az ajánlatkérésekben, a biztonsági mellékletekben és az elfogadási kapukban.

A közös üzenet egyszerű: a vásárló szervezetnek tudnia kell, mit vásárol, milyen kockázatot vesz át, és milyen bizonyítékot tud előállítani, amikor szabályozó hatóságok, ügyfelek vagy auditorok kérdeznek.

Az ISO 27001 kontrollgerince a beszállítói bizonyossághoz

A leghatékonyabb secure-by-demand beszerzési modell nem jogszabályonként építkezik. Kontrollalapú. A Clarysec az ISO/IEC 27001:2022 szabványt használja az IBIR gerinceként, amelyet az ISO/IEC 27002:2022 kontrollútmutatása és a Zenith Controls keresztmegfelelési leképezése támogat.

A Zenith Controls rendszerben a beszállítói bizonyosság az ISO/IEC 27002:2022 5.19, 5.20 és 5.21 kontrolljai köré épül. Ezek nem elszigetelt ellenőrzőlista-elemek. Beszerzési életciklust alkotnak.

A Zenith Controls ezeket az ISO kontrollokat szabályozási és auditelvárásokra képezi le. Nem hoz létre Zenith Controls nevű különálló, saját kontrollokat. Segít a csapatoknak megérteni, hogyan támogatják az ISO/IEC 27002:2022 kontrollok a NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT-orientált bizonyosságot.

A támogató kontrollhálózat is számít. A beszállítói bizonyosság kapcsolódik az eszközkezeléshez, hozzáférés-szabályozáshoz, felhőbiztonsághoz, sérülékenységkezeléshez, naplózáshoz, incidenskezeléshez, az IKT üzletmenet-folytonosságra való felkészültségéhez, biztonságos fejlesztéshez, alkalmazásbiztonsághoz, konfigurációkezeléshez, biztonsági mentéshez, redundanciához, jogi megfeleléshez, adatvédelemhez, változáskezeléshez és független felülvizsgálathoz. A beszerzés koordinálja a folyamatot, de a kockázattulajdonosi felelősségnek ki kell terjednie az üzleti tulajdonosra, az információbiztonságra, a jogi területre, az adatvédelemre, az IT-re, a pénzügyre és a szolgáltatásgazdára.

Clarysec szabályzati kapuk az aláírás előtt

A Clarysec szabályzati modellje tudatosan a folyamat elejére helyezi a beszállítói bizonyosságot. A legerősebb megfogalmazás ott jelenik meg, ahol lennie kell: a megállapodások aláírása előtt, a felhő-előfizetések aktiválása előtt és az adatok megosztása előtt.

A Clarysec Harmadik fél és beszállítói biztonsági szabályzat KKV-változata kimondja:

A beszállítói kockázatokat a megállapodások aláírása vagy a hozzáférés megadása előtt értékelni és dokumentálni kell.

Ez a „célkitűzések” szakasz 3.3 szabályzati pontjából származik. A pont rövid, mert a kontrollcél nem képezheti vita tárgyát: nincs kockázatértékelés, nincs szerződés, nincs hozzáférés.

Vállalati környezetekben a Clarysec Harmadik fél és beszállítói biztonsági szabályzata megerősíti a szerződéskötés előtti kaput:

Minden új beszállítónak dokumentált biztonsági értékelésen kell átesnie a szerződés végrehajtása előtt.

Ez „a szabályzat végrehajtásának követelményei” szakasz 6.1.1 szabályzati pontjából származik. Ugyanez a szabályzat az „irányítási követelmények” szakasz 5.3.4 szabályzati pontjában azonosítja az „auditálási, vizsgálati és biztonsági bizonyítékok kérésére vonatkozó jogokat” is.

Felhő- és SaaS-beszerzés esetén a KKV Felhőszolgáltatások használatára vonatkozó szabályzat gyakorlati jóváhagyási kaput ad hozzá:

A felhőszolgáltatások minden használatát a bevezetés vagy előfizetés előtt az ügyvezetőnek (GM) felül kell vizsgálnia és jóvá kell hagynia.

Ez az „irányítási követelmények” szakasz 5.1 szabályzati pontjából származik. Egy kis szervezetben ez a jóváhagyás a felhőirányítási testület megfelelője lehet. Egy vállalatnál munkafolyamattá válik a beszerzés, a biztonság, az adatvédelem és az architektúra között. A vállalati Felhőszolgáltatások használatára vonatkozó szabályzat a szerződéses felhőkövetelményeket is támogatja, beleértve a CSP-szerződésekben szereplő kikényszeríthető rendelkezéseket.

Szoftverbeszerzés esetén a vállalati Alkalmazásbiztonsági követelmények szabályzata egyértelmű:

A szoftverbeszerzési vagy kiszervezési megállapodásoknak biztonsági követelményeket kell tartalmazniuk az ajánlatkérésekben, szerződésekben és SLA-kban, beleértve a sérülékenységek helyesbítő intézkedéseinek határidejére és a harmadik fél auditálási jogára vonatkozó rendelkezéseket.

Ez az „irányítási követelmények” szakasz 5.4 szabályzati pontjából származik. Figyelje meg a sorrendet: ajánlatkérések, szerződések és SLA-k. A biztonság már a piaci megkeresés szakaszában megjelenik, nem utólagos mellékletként a nyertes kiválasztása után.

GDPR-vezérelt beszerzés esetén a Clarysec KKV Jogi és szabályozói megfelelési szabályzat előírja:

Az adatfeldolgozási szerződés (DPA) záradékairól vagy azzal egyenértékű szerződéses feltételekről meg kell állapodni, mielőtt bármilyen személyes vagy érzékeny adatot megosztanak.

Ez „a szabályzat végrehajtásának követelményei” szakasz 6.3.2 szabályzati pontjából származik. Ez megelőzi az egyik leggyakoribb SaaS-bevezetési hibát: személyes adatok feltöltését egy eszközbe az adatfeldolgozói feltételek, az adatsértési kötelezettségek és a további adatfeldolgozói feltételek elfogadása előtt.

Beszállítói alkalmazásbiztonság esetén a KKV Alkalmazásbiztonsági követelmények szabályzata megköveteli, hogy a beszerzés:

határozza meg a sérülékenység-feltárásra, válaszidőkre és javításkezelésre vonatkozó kötelezettségeket.

Ez az „irányítási követelmények” szakasz 5.3.2 szabályzati pontjából származik. A szabályzat azt is kimondja:

A GM-nek adott esetben dokumentációt vagy tanúsításokat (pl. SOC 2, ISO 27001, biztonsági tesztjelentések) kell kérnie a beszállítói megfelelés bizonyítékaként.

Ez „a szabályzat végrehajtásának követelményei” szakasz 6.3.2 szabályzati pontjából származik. A kulcsszó: bizonyíték. A secure-by-demand beszerzés nem bizalmi nyilatkozatokra épül. Felülvizsgálható bizonyítékokra épül.

A Zenith Blueprint beszerzési kapuja

A Zenith Blueprint a beszállítói biztonságot működtetett kontrollként kezeli, nem beszerzési szlogenként. A Controls in Action szakaszban a Step 23 a szervezeti kontrollokat fedi le 5.19-től 5.37-ig, beleértve a beszállítói kapcsolatok információbiztonságát.

A Blueprint így magyarázza:

A folyamat a beszállítói besorolással kezdődik. Nem minden beszállító hordoz azonos kockázatot. Egy takarítószolgálat fizikai hozzáféréssel rendelkezhet az irodákhoz, de nem a hálózatokhoz. Egy penetrációs teszteléssel foglalkozó cég vagy tárhelyszolgáltató ezzel szemben mély technikai hozzáféréssel rendelkezhet az infrastruktúra lényegéhez. A besorolás során mérlegelni kell, hogy a beszállító közvetlenül kezeli vagy feldolgozza-e az Ön információit, biztosít-e olyan infrastruktúrát vagy platformokat, amelyeken Ön működik, kezel-e vagy karbantart-e rendszereket az Ön nevében, és kompromittálódása hatással lehet-e a bizalmassági, sértetlenségi vagy rendelkezésre állási célokra.

Az 5.20 kontroll esetében a Blueprint közvetlenül fogalmaz:

A beszállítói megállapodásokban jellemzően kezelt fő területek közé tartoznak a titoktartási kötelezettségek; a hozzáférés-szabályozási felelősségek; az adatvédelemre, titkosításra, biztonságos átvitelre, biztonsági mentésre és rendelkezésre állási vállalásokra vonatkozó technikai és szervezési intézkedések; az incidensbejelentési határidők és előírások; az auditálási jog, beleértve a gyakoriságot, hatókört és a releváns bizonyítékokhoz való hozzáférést; az alvállalkozói kontrollok; valamint a szerződés megszűnéséhez kapcsolódó rendelkezések, például az adatok visszaadása vagy megsemmisítése, az eszközvisszavétel és a fiókok deaktiválása.

A következtetés szerint az 5.20 kontroll „az utolsó érdemi tárgyalási eszköz” és „a beszerzési kapuhoz tartozik”. A szerződés aláírása után a tárgyalási mozgástér csökken. Aláírás előtt a bizonyítékok és kötelezettségek a vásárlás feltételeivé tehetők.

Kiszervezett fejlesztés esetén a Controls in Action szakasz Step 21, 8.30 kontrollja további beszerzési követelményt ad hozzá. A Blueprint kimondja:

Ennek a kontrollnak a középpontjában az az elv áll, hogy a biztonságnak szerződéses követelménynek kell lennie, nem szóbeli elvárásnak.

A kiszervezett csapatoknak ugyanazoknak a biztonságos fejlesztési szabványoknak kell megfelelniük, mint a belső csapatoknak, beleértve a statikus elemzést, a társfelülvizsgálatot, a titkosítást, a többtényezős hitelesítést az adattárakhoz, valamint az átláthatóságot a kód, az architekturális döntések, a sérülékenységek, a változtatási kérelmek, a CI/CD-naplók és a vizsgálati eredmények tekintetében.

Secure-by-demand RFP-kapu kialakítása egy délután alatt

Tegyük fel, hogy a szervezet ügyfélelemzési platformot szeretne. A platform ügyfélazonosítókat, viselkedési eseményeket, támogatási metaadatokat és tranzakciós hivatkozásokat fog feldolgozni. Az üzleti tulajdonos gyors jóváhagyást szeretne. A biztonsági csapatnak egy hete van.

Kezdje egy beszerzési kapu nyilvántartási bejegyzéssel, forrásdokumentumként használva a Harmadik fél és beszállítói biztonsági szabályzatot, az Alkalmazásbiztonsági követelmények szabályzatát, a Felhőszolgáltatások használatára vonatkozó szabályzatot, a Jogi és szabályozói megfelelési szabályzatot, valamint a Zenith Blueprint Step 23 lépését.

Csatoljon secure-by-demand kérdőívet az ajánlatkéréshez. Kerülje az olyan általános kérdéseket, mint: „Titkosítják az adatokat?” Tegyen fel bizonyítékalapú kérdéseket:

1. Nyújtsa be aktuális független biztonsági bizonyossági jelentését, tanúsítványát vagy egyenértékű kontrollbizonyítékát.
2. Azonosítsa a tárhelyhelyszíneket, az adattárolás földrajzi helyére vonatkozó lehetőségeket, a biztonsági mentési helyszíneket és a támogatási hozzáférési helyszíneket.
3. Nyújtsa be a DPA-t, a további adatfeldolgozók listáját és a további adatfeldolgozói változások értesítési folyamatát.
4. Erősítse meg az incidensbejelentési határidőket, beleértve a 24 órás korai figyelmeztetés támogatását, ahol NIS2 munkafolyamatok aktiválódhatnak, valamint a szakaszos jelentéstétel támogatását DORA hatálya alá tartozó ügyfelek számára.
5. Nyújtsa be a sérülékenység-feltárási szabályzatot, a súlyosság szerinti javítási SLA-kat és a közelmúltbeli sérülékenység-helyesbítési irányítás bizonyítékait.
6. Nyújtson be termékbiztonsági bizonyítékokat, például a biztonságos fejlesztési életciklus leírását, a penetrációs teszt összefoglalóját, SBOM-ot vagy komponensátláthatósági nyilatkozatot, valamint a biztonsági frissítések támogatási időszakát.
7. Erősítse meg a többtényezős hitelesítést, a legkisebb jogosultság elvét, a naplózást, az adminisztratív hozzáférés monitorozását, valamint az ügyfél auditálási vagy bizonyítékkérési jogait.
8. Mutassa be az exportot, törlést, visszaadást, megszüntetési támogatást és átállási segítségnyújtást.
9. Sorolja fel a szolgáltatást támogató lényeges alvállalkozókat és IKT-függőségeket.
10. Erősítse meg, hogy az ügyféladatokat használják-e képzésre, elemzésre, termékfejlesztésre vagy AI-modellfejlesztésre, és azonosítsa a jogalapot vagy az adatfeldolgozói ügyfélutasítási modellt.

Ezután értékelje a beszállítót a tárgyalás előtt.

Végül frissítse a kockázati nyilvántartást és az alkalmazhatósági nyilatkozatot. A kockázatkezelési nyilvántartásnak meg kell mutatnia, miért alkalmazandók az ISO/IEC 27002:2022 5.19, 5.20 és 5.21 kontrolljai, mely szerződéses és technikai követelményeket választották ki, ki a maradványkockázat tulajdonosa, és milyen felügyeleti gyakoriság alkalmazandó. Ha az üzlet a hiányosságok ellenére tovább kíván haladni, formális kockázatelfogadási bejegyzést kell használni lejárati dátummal, kompenzáló kontrollokkal és felsővezetői jóváhagyással.

Szerződéses záradékok, amelyek a szabályozást kikényszeríthető kötelezettségekké alakítják

A biztonsági elvárásoknak szerződéses vállalásokká kell válniuk. Egy tanúsítvány hasznos lehet, de ritkán válaszol minden kérdésre az adott szolgáltatásról, adatkezelési helyről, alvállalkozókról, támogatási modellről, incidensvállalásokról vagy kilépési jogokról.

Ez a táblázat gyakorlati hidat képez a jogi kötelezettségek és a beszerzési munka között. Segít abban is, hogy a jogi, biztonsági és beszerzési területek ugyanazon kontrollalapvonal alapján tárgyaljanak.

Keresztmegfelelési leképezés: egy beszállítói fájl, több kötelezettség

Az ISO/IEC 27001:2022 gerincként történő használatának előnye, hogy egyetlen beszállítói bizonyossági fájl több szabályozási párbeszédet is támogatni tud.

A NIST CSF 2.0 kommunikációs rétegként hasznos. GOVERN funkciója a jogi, szabályozási, szerződéses, adatvédelmi és függőségi tudatosságot hangsúlyozza. GV.SC ellátási lánci eredményei ellátásilánc-kockázatkezelési folyamatokat, beszállítói szerepköröket, kritikusság szerinti beszállítói priorizálást, szerződéses követelményeket, kellő gondosságot, monitorozást, incidens-tervezést és megszüntetési tervezést követelnek meg.

Ez tisztán leképezhető a Zenith Blueprint Step 23 lépésére és az ISO/IEC 27002:2022 5.19–5.21 kontrolljaira, ahogyan azokat a Zenith Controls tartalmazza. Az igazgatóság számára is érthető nyelvet ad: jelenlegi állapot, célállapot, hiányosság, kockázat, intézkedés, felelős és dátum.

Mit fognak kérdezni az auditorok

Egy erős secure-by-demand beszerzési folyamatnak különböző auditori nézőpontokból is meg kell állnia.

Egy ISO/IEC 27001:2022 auditor az IBIR környezetével és alkalmazási területével kezdi. Meg fogja kérdezni, hogy a beszállítói interfészek és függőségek szerepelnek-e, hogy az érdekelt felek követelményei tartalmazzák-e a NIS2, DORA, GDPR és ügyfélszerződési követelményeket, és hogy a beszállítói kockázatokat következetesen értékelik-e a kockázatértékelési módszertan szerint. Követni fogja a nyomvonalat a kockázatkezelésen, az alkalmazhatósági nyilatkozaton, a beszállítói kontrollokon, a működési bizonyítékokon, a belső auditon és a vezetőségi átvizsgáláson keresztül.

Egy DORA-felülvizsgáló az IKT által támogatott üzleti funkciókra, a kritikus vagy fontos funkciókra, a harmadik felekkel kapcsolatos függőségi bejegyzésekre, a szerződéses záradékokra, az auditálási és hozzáférési jogokra, az incidensekkel kapcsolatos együttműködésre, a rezilienciatesztelésre, a kilépési stratégiákra és a koncentrációs kockázatra fog összpontosítani. Ha egy SaaS kritikus vagy fontos funkciót támogat, egy könnyű beszállítói kérdőív nem lesz elegendő.

Egy NIS2 hatóság meg fogja kérdezni, hogyan értékelte a szervezet a beszállítói kiberbiztonsági gyakorlatokat, a közvetlen beszállítói sérülékenységeket, az incidensbejelentési támogatást, a folytonossági függőségeket és a biztonságos beszerzési döntéseket. Ellenőrizni fogja, hogy a beszállítói bizonyosság támogatja-e a szervezet saját Article 21 és Article 23 szerinti kötelezettségeit.

Egy GDPR-felülvizsgáló meg fogja kérdezni, hogy az adatkezelői és adatfeldolgozói szerepköröket megértették-e az adatkezelés megkezdése előtt, hogy a DPA-ról vagy egyenértékű feltételekről megállapodtak-e az adatok megosztása előtt, hogy a további adatfeldolgozókat közzétették-e, hogy a biztonsági intézkedések megfelelőek-e, hogy az adatsértési együttműködés szerződéses-e, és hogy az adatok visszaadása vagy törlése kikényszeríthető-e.

Egy COBIT 2019 vagy ISACA-típusú auditor az irányításra és az elszámoltathatóságra összpontosít: ki hagyta jóvá a beszállítót, milyen kockázatot fogadtak el, betartották-e a szabályzati követelményeket, nyomon követik-e a kivételeket, és egyensúlyban voltak-e a hasznok, a kockázatok és az erőforrások.

A bizonyítékcsomagnak tartalmaznia kell a beszállítói besorolást, az üzleti tulajdonos jóváhagyását, a kockázatértékelést, az RFP biztonsági követelményeit, a beszállítói válaszokat, a DPA-t, a biztonsági mellékletet, az SLA-t, az auditálási jogokat, a további adatfeldolgozói nyilvántartást, a sérülékenységi vállalásokat, az incidenszáradékokat, a felhőhelyszínek bizonyítékait, a naplózási és titkosítási bizonyítékokat, a kilépési feltételeket, az újraértékelési bejegyzéseket, a kivételeket és az alkalmazhatósági nyilatkozat leképezését.

Gyakori hibaminták a szoftverbeszerzésben

Az első hiba, amikor a beszerzést kereskedelmi munkafolyamatként, a biztonságot pedig technikai munkafolyamatként kezelik. Mire a biztonsági terület megkapja a szerződést, az üzlet pszichológiailag már elköteleződött, a bevezetési dátumot bejelentették, és a tárgyalási mozgástér gyenge.

A második hiba a bizonyítékhelyettesítés. A beszállító benyújt egy tanúsítványt, a vevő pedig feltételezi, hogy ez minden kérdésre választ ad. A tanúsítás segíthet, de lehet, hogy nem fedi le a pontos terméket, tárhelyrégiót, támogatási modellt, alvállalkozói láncot, incidenskötelezettségeket, AI-adathasználatot vagy kilépési követelményeket.

A harmadik hiba az alsóbb szintű kockázat figyelmen kívül hagyása. Egy SaaS-beszállító támaszkodhat felhőalapú tárhelyre, analitikai eszközökre, támogatási platformokra, offshore csapatokra, AI-modellszolgáltatókra és fizetési feldolgozókra. Az ISO/IEC 27002:2022 5.21 kontroll megköveteli az IKT ellátási láncra fordított figyelmet a közvetlen beszállító mögött. A DORA alatt ez az alvállalkozásokat és a koncentrációs kockázatot érinti. A GDPR alatt a további adatfeldolgozókhoz kapcsolódik. A NIS2 alatt a közvetlen beszállítói sérülékenységekhez és a beszállítói kiberbiztonsági gyakorlatokhoz kapcsolódik.

A negyedik hiba a gyenge incidensmegfogalmazás. Egy olyan szerződés, amely szerint „a beszállító haladéktalanul értesíti az ügyfelet”, nem feltétlenül támogatja a NIS2 korai figyelmeztetést, a DORA szakaszos jelentéstételt, az ügyfélkommunikációt vagy a belső eszkalációt. Az incidenszáradékoknak határidőkre, kiváltó eseményekre, kapcsolattartókra, együttműködési kötelezettségekre és bizonyítékkötelezettségekre van szükségük.

Az ötödik hiba a tisztázatlan kilépési jogok. Ha egy beszállító bizonytalanná, nem megfelelővé, felvásárolttá, fizetésképtelenné vagy stratégiailag alkalmatlanná válik, a vevőnek exportra, törlésre, átállási támogatásra, fiókdeaktiválásra és megsemmisítési bizonyítékra van szüksége. A kilépés nem jogi utógondolat. Rezilienciakontroll.

A beszerzési kaputól az élő beszállítói bizonyosságig

A secure-by-demand beszerzés nem ér véget az aláíráskor. Egy érett, Clarysec-stílusú beszállítói életciklus öt szakaszból áll.

Magas kockázatú beszállítók esetén a felügyeletnek tartalmaznia kell a bizonyítékok frissítését, biztonsági felülvizsgálati értekezleteket, incidens asztali gyakorlatban való részvételt, hozzáférési felülvizsgálatot, sérülékenységi és javításkezelési jelentéstételt, szolgáltatásváltozás-felülvizsgálatot és további adatfeldolgozói frissítéseket. Alacsonyabb kockázatú beszállítók esetén az éves felülvizsgálat elegendő lehet. Az ISO 27001 skálázhatósága, a NIS2 arányossága és a DORA arányossága mind támogatja a testreszabást, de a testreszabást indokolni és dokumentálni kell.

A Clarysec következő lépése

A következő kockázatos SaaS-beszerzés nem fog várni egy tökéletes irányítási újratervezésre. Kezdje a következő beszerzési kérelemmel.

Használja a Zenith Blueprint: egy auditor 30 lépéses ütemterve anyagot a Step 23 beszállítói kapcsolati kontrollok és a Step 21 kiszervezett fejlesztési kontrollok bevezetéséhez. Használja a Zenith Controls rendszert az ISO/IEC 27002:2022 5.19, 5.20 és 5.21 kontrolljainak NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT-orientált auditelvárásokra történő leképezéséhez. Használja a Clarysec szabályzattárát, beleértve a Harmadik fél és beszállítói biztonsági szabályzatot, az Alkalmazásbiztonsági követelmények szabályzatát, a Felhőszolgáltatások használatára vonatkozó szabályzatot és a Jogi és szabályozói megfelelési szabályzatot, hogy a kapu kikényszeríthető legyen.

A következő szerződés aláírása előtt követelje meg a beszállítói besorolást, a biztonsági bizonyítékokat, a DPA-felkészültséget, az incidensvállalásokat, a sérülékenységkezelést, az alvállalkozói átláthatóságot, az auditálási jogokat és a kilépési feltételeket.

Ez a secure-by-demand beszerzés. Így alakítják a CISO-k a szabályozói nyomást beszerzési erővé. Így fordítják a megfelelőségi vezetők az átfedő kötelezettségeket egyetlen bizonyítékfájllá. Így látják az auditorok, hogy a beszállítói kockázatot a függőség kialakulása előtt mérlegelték. És így vásárolnak az üzleti tulajdonosok gyorsabban szoftvert anélkül, hogy kezeletlen kockázatot örökölnének.

Készen áll arra, hogy a következő szoftverbeszerzését auditkész kontrollá alakítsa? Ismerje meg a Clarysec integrált szabályzatcsomagját, töltse le a Zenith Blueprint anyagot, tekintse át a Zenith Controls rendszert, vagy foglaljon demót egy olyan secure-by-demand beszerzési program felépítéséhez, amely megállja a helyét a NIS2, DORA, GDPR, CRA elvárások és a valós auditori vizsgálat előtt.