Nabava programske opreme z varnostjo kot predpogojem v letu 2026

Torek zjutraj je, začetek leta 2026, in Maria, vodja informacijske varnosti hitro rastočega evropskega plačilnega podjetja, upravnemu odboru predstavlja gradivo. Zadnja točka dnevnega reda bi morala biti rutinska: odobritev nove platforme za odkrivanje goljufij, podprte z umetno inteligenco. Dobavitelj ima prepričljivo predstavitev, časovno omejen popust, enostranski varnostni pregled in standardno pogodbo.

Nato se začnejo vprašanja.

Generalni direktor vpraša: »Kako vemo, da je ta platforma varna? Naše stranke iz finančnega sektorja zahtevajo dokazila o skladnosti z DORA, ta dobavitelj pa postaja del naše kritične infrastrukture.«

Pravna služba vpraša, ali je pogodba o obdelavi osebnih podatkov pripravljena, kje se bodo obdelovali podatki strank iz EU in ali so podobdelovalci razkriti. Vodja operativne odpornosti sprašuje o načrtovanju izstopa, izvozu varnostnih kopij in neprekinjenosti kritičnih funkcij. Inženir za varnost produktov zahteva razkritje ranljivosti, dokazila o nameščanju popravkov in SBOM ali enakovredno izjavo o preglednosti komponent. Nabava postavi vprašanje, zaradi katerega tveganje dobavitelja postane drago: »Ali lahko odobrimo zdaj in dokumente zberemo po podpisu?«

To je trenutek, ko sodobna nabava programske opreme postane kontrolni ukrep ali pa prihodnje poročilo o incidentu.

V letu 2026 se varna nabava programske opreme ne more zanašati na dobro voljo po sklenitvi pogodbe. Varnost dobavne verige po NIS2, tveganje tretjih oseb IKT po DORA, odgovornost obdelovalca po GDPR in pričakovanja glede varnosti produktov po Cyber Resilience Act so zagotovila o dobaviteljih premaknili na točko odločitve o nabavi. Kupci potrebujejo nabavo programske opreme z varnostjo kot predpogojem, pri kateri naročnik pred nakupom določi varnostna dokazila, pogodbene klavzule, kontrolne točke uvajanja in operativne odgovornosti.

Za stranke Clarysec odgovor ni še ena preglednica, ki obtiči v e-pošti. Odgovor je sistem nabavnih kontrolnih ukrepov, usklajen z ISO/IEC 27001:2022, preslikan prek politik Clarysec, Zenith Blueprint: 30-koračni načrt presojevalca in Zenith Controls, tako da ima vsak nakup programske opreme ali SaaS zagovorljivo sled od poslovne potrebe do odločitve o tveganju dobavitelja.

Varnost kot predpogoj je nov kontrolni ukrep pri nabavi programske opreme

O vgrajeni varnosti se običajno razpravlja z vidika dobavitelja. Varnost kot predpogoj je disciplina na strani kupca: organizacija zavrne nakup programske opreme, če dobavitelj ne more dokazati, da so varnost, zasebnost, odpornost, obravnava ranljivosti in preverljivost vgrajene v ponudbo.

To spremeni nabavni pogovor. Namesto vprašanja »Ali imate varnost?« nabava postavi natančnejša vprašanja:

• Katere podatke boste obdelovali, kje in v kateri pravni vlogi?
• Katera poslovna funkcija bo odvisna od vas in kako kritična je?
• Katera dokazila potrjujejo, da vaše kontrole delujejo, ne le da so dokumentirane?
• Katerim rokom obveščanja o incidentih se boste zavezali?
• Katera dokazila o razkritju ranljivosti, nameščanju popravkov, SBOM ali VEX lahko predložite?
• Kateri podizvajalci ali podobdelovalci bodo imeli stik z našimi podatki ali storitvijo?
• Ali lahko med trajanjem pogodbe izvedemo presojo, pregled ali zahtevamo dokazila?
• Kaj se zgodi ob prenehanju, migraciji, kršitvi, insolventnosti ali regulativni poizvedbi?

ISO/IEC 27001:2022 zagotavlja hrbtenico sistema upravljanja za ta premik. Klavzula 4 zahteva, da organizacija razume kontekst, zainteresirane strani in obseg ISMS, vključno z zunanjimi regulativnimi in dobaviteljskimi zahtevami. Klavzula 5 tveganje dobaviteljev pretvori v odgovornost vodstva in upravljanja. Klavzula 6 zahteva oceno tveganja, obravnavo tveganja, izbiro kontrolnih ukrepov, izjavo o uporabnosti in odločitve o preostalem tveganju. Klavzula 8 zahteva nadzorovano izvajanje procesov, vključno z zunanje zagotovljenimi procesi. Klavzula 9 zahteva spremljanje, notranjo presojo in vodstveni pregled.

To pomeni, da nabava programske opreme ni zgolj komercialni delovni tok. Postane upravljan in preverljiv proces ISMS. Regulatorji in presojevalci vse pogosteje sprašujejo, zakaj je organizacija sprejela dobavitelja, preden je razumela tveganje. Nabava z varnostjo kot predpogojem daje jasen odgovor: tveganje je bilo ocenjeno, obravnavano, pogodbeno urejeno in dodeljeno, preden je nastala odvisnost.

Zakaj se NIS2, DORA, GDPR in CRA srečajo pri izbiri dobavitelja

Mariin upravni odbor postavlja prava vprašanja, ker lahko en sam dobavitelj programske opreme sproži več obveznosti hkrati.

NIS2 se uporablja glede na sektor, velikost in kritičnost, pri čemer Priloga I in Priloga II v obseg vključujeta številne digitalne, finančne in infrastrukturne organizacije, ponudnike upravljanih storitev ter organizacije, odvisne od oblaka. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z varnostjo dobavne verige, varno pridobitvijo, varnim razvojem in vzdrževanjem, obravnavo ranljivosti, nadzorom dostopa, upravljanjem sredstev, neprekinjenostjo, obravnavanjem incidentov in oceno učinkovitosti kontrolnih ukrepov. Article 21(3) posebej zahteva pozornost na ranljivosti neposrednih dobaviteljev in prakse kibernetske varnosti dobaviteljev. Article 23 uvaja pričakovanja glede postopnega poročanja o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah in obvestilom v 72 urah.

DORA se od 17. januarja 2025 uporablja za finančne subjekte v obsegu. Uvaja enotne zahteve za upravljanje tveganj IKT, poročanje o incidentih, povezanih z IKT, testiranje digitalne operativne odpornosti in upravljanje tveganj tretjih oseb IKT. DORA je pri nabavi posebej predpisovalna. Finančni subjekti potrebujejo strategije za tveganja tretjih oseb IKT, registre dogovorov o storitvah IKT, skrbni pregled, analizo tveganja koncentracije, pisne pogodbe z določbami o varnosti in odpornosti, pravice do presoje in dostopa, obveznosti sodelovanja, pravice do odpovedi in načrte izstopa. Article 28 in Article 30 sta osrednja za tveganje tretjih oseb IKT in pogodbene kontrolne ukrepe, medtem ko Article 17 do Article 23 oblikujejo upravljanje incidentov in poročanje.

GDPR doda kontrolno točko odgovornosti obdelovalca. Article 5, Article 28, Article 32, Article 33 in Article 34 zahtevajo odgovornost, pogodbe z obdelovalci, ustrezno varnost, sodelovanje pri obveščanju o kršitvah in obravnavo vpliva na posameznike, na katere se nanašajo podatki. Dobavitelj SaaS, ki obdeluje osebne podatke, ni zgolj dobavitelj. Postane del profila skladnosti upravljavca. DPA, tehnični in organizacijski ukrepi, seznam podobdelovalcev, zaščitni ukrepi pri prenosih, pravila hrambe in obveznosti izbrisa morajo biti razumljeni pred začetkom obdelave.

Pričakovanja CRA dodajo zagotovila o produktu. Tudi kadar kupec ni proizvajalec, morajo nabavne ekipe zahtevati dokazila o varnem razvoju, obravnavi ranljivosti, podpori produktu, varnostnih posodobitvah, usklajenem razkrivanju ranljivosti in preglednosti komponent, kot je SBOM ali enakovredna izjava. Te zahteve sodijo v RFP, varnostne priloge in sprejemne kontrolne točke.

Skupna tema je preprosta: kupujoča organizacija mora vedeti, kaj kupuje, katero tveganje uvaža in katera dokazila lahko predloži, ko vprašajo regulatorji, stranke ali presojevalci.

Kontrolna hrbtenica ISO 27001 za zagotovila o dobaviteljih

Najučinkovitejši model nabave z varnostjo kot predpogojem ni urejen po posameznih predpisih. Izhaja iz kontrolnih ukrepov. Clarysec uporablja ISO/IEC 27001:2022 kot hrbtenico ISMS, podprto s smernicami kontrolnih ukrepov ISO/IEC 27002:2022 in preslikavo navzkrižne skladnosti v Zenith Controls.

V Zenith Controls so zagotovila o dobaviteljih zasidrana v kontrolnih ukrepih ISO/IEC 27002:2022 5.19, 5.20 in 5.21. To niso ločene postavke kontrolnega seznama. Skupaj tvorijo življenjski cikel nabave.

Zenith Controls te kontrolne ukrepe ISO preslika čez regulativna in revizijska pričakovanja. Ne ustvarja ločenih lastniških kontrolnih ukrepov z imenom Zenith Controls. Ekipam pomaga razumeti, kako kontrolni ukrepi ISO/IEC 27002:2022 podpirajo NIS2, DORA, GDPR, NIST CSF 2.0 in zagotovila, usmerjena v COBIT.

Pomembno je tudi podporno omrežje kontrolnih ukrepov. Zagotovila o dobaviteljih se povezujejo z upravljanjem sredstev, nadzorom dostopa, varnostjo v oblaku, upravljanjem ranljivosti, beleženjem, upravljanjem incidentov, pripravljenostjo IKT za neprekinjeno poslovanje, varnim razvojem, varnostjo aplikacij, upravljanjem konfiguracije, varnostnim kopiranjem, redundanco, pravno skladnostjo, zasebnostjo, upravljanjem sprememb in neodvisnim pregledom. Nabava usklajuje proces, lastništvo tveganja pa mora vključevati lastnika poslovnega procesa, informacijsko varnost, pravno službo, zasebnost, IT, finance in lastnika storitve.

Kontrolne točke politik Clarysec pred podpisom

Model politik Clarysec namerno premakne zagotovila o dobaviteljih navzgor v proces. Najmočnejše besedilo je tam, kjer mora biti: pred podpisom dogovorov, pred aktivacijo naročnin v oblaku in pred deljenjem podatkov.

Različica Clarysecove Politike varnosti tretjih oseb in dobaviteljev za mala in srednja podjetja določa:

Ocenite in dokumentirajte tveganja dobaviteljev, preden so dogovori podpisani ali dostop odobren.

To izhaja iz razdelka »Cilji«, klavzula politike 3.3. Klavzula je kratka, ker je namen kontrolnega ukrepa nedvoumen: brez ocene tveganja ni pogodbe in ni dostopa.

Za poslovna okolja Clarysecova Politika varnosti tretjih oseb in dobaviteljev krepi predpogodbeno kontrolno točko:

Vsi novi dobavitelji morajo pred sklenitvijo pogodbe opraviti dokumentirano varnostno presojo.

To izhaja iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1. Ista politika v razdelku »Zahteve upravljanja«, klavzula politike 5.3.4, opredeljuje tudi »pravice do presoje, pregleda in zahteve za varnostna dokazila«.

Za nakup oblaka in SaaS Clarysecova Politika uporabe storitev v oblaku za mala in srednja podjetja dodaja praktično odobritveno kontrolno točko:

Vsaka uporaba storitev v oblaku mora biti pred implementacijo ali naročnino pregledana in odobrena s strani generalnega direktorja (GM).

To izhaja iz razdelka »Zahteve upravljanja«, klavzula politike 5.1. V majhni organizaciji je ta odobritev lahko enakovredna odboru za upravljanje oblaka. V poslovnem okolju postane delovni tok med nabavo, varnostjo, zasebnostjo in arhitekturo. Poslovna Politika uporabe storitev v oblaku podpira tudi pogodbene zahteve za oblak, vključno z izvršljivimi določbami v pogodbah s CSP.

Pri pridobivanju programske opreme je poslovna Politika zahtev za varnost aplikacij izrecna:

Pridobivanje programske opreme ali ureditve zunanjega izvajanja morajo vključevati varnostne zahteve v RFP, pogodbah in SLA, vključno z določbami o rokih za odpravo ranljivosti in pravicah tretjih oseb do presoje.

To izhaja iz razdelka »Zahteve upravljanja«, klavzula politike 5.4. Opazite zaporedje: RFP, pogodbe in SLA. Varnost se pojavi že v fazi stika s trgom, ne kot priloga po oddaji naročila.

Za nabavo, ki jo usmerja GDPR, Clarysecova Politika pravne in regulativne skladnosti za mala in srednja podjetja zahteva:

Klavzule pogodbe o obdelavi podatkov ali enakovredna pogodbena določila morajo biti dogovorjena, preden se delijo kakršni koli osebni ali občutljivi podatki.

To izhaja iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.3.2. S tem se prepreči ena najpogostejših napak pri uvajanju SaaS: nalaganje osebnih podatkov v orodje, preden so dogovorjeni pogoji obdelovalca, obveznosti ob kršitvah in pogoji za podobdelovalce.

Za varnost aplikacij dobaviteljev Clarysecova Politika zahtev za varnost aplikacij za mala in srednja podjetja zahteva, da nabava:

določi obveznosti za razkritje ranljivosti, odzivne čase in nameščanje popravkov.

To izhaja iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.2. Politika določa tudi:

GM mora zahtevati dokumentacijo ali certifikate (npr. SOC 2, ISO 27001, poročila o varnostnem testiranju) kot dokazilo o skladnosti dobavitelja, kadar je to primerno.

To izhaja iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.3.2. Ključna beseda so dokazila. Nabava z varnostjo kot predpogojem ne temelji na izjavah o zaupanju. Temelji na artefaktih, ki jih je mogoče pregledati.

Nabavna kontrolna točka Zenith Blueprint

Zenith Blueprint obravnava varnost dobaviteljev kot izveden kontrolni ukrep, ne kot nabavni slogan. V fazi Controls in Action korak 23 pokriva organizacijske ukrepe 5.19 do 5.37, vključno z informacijsko varnostjo v odnosih z dobavitelji.

Blueprint pojasnjuje:

Začne se z razvrstitvijo dobaviteljev. Vsi dobavitelji ne prinašajo enakega tveganja. Čistilni servis ima lahko fizični dostop do pisarn, ne pa tudi do omrežij. Podjetje za penetracijsko testiranje ali ponudnik gostovanja v oblaku pa ima lahko globok tehnični dostop do samega jedra vaše infrastrukture. Razvrstitev mora upoštevati, ali dobavitelj neposredno ravna z vašimi informacijami ali jih obdeluje, ali zagotavlja infrastrukturo ali platforme, na katerih delujete, ali v vašem imenu upravlja ali vzdržuje sisteme ter ali bi njegova kompromitacija lahko vplivala na vaše cilje zaupnosti, celovitosti ali razpoložljivosti.

Za kontrolni ukrep 5.20 je Blueprint neposreden:

Ključna področja, ki so običajno obravnavana v dogovorih z dobavitelji, vključujejo obveznosti glede zaupnosti; odgovornosti za nadzor dostopa; tehnične in organizacijske ukrepe za varstvo podatkov, šifriranje, varen prenos, varnostno kopiranje in zaveze glede razpoložljivosti; roke in protokole poročanja o incidentih; pravico do presoje, vključno s pogostostjo, obsegom in dostopom do relevantnih dokazil; kontrole podizvajalcev; ter določbe ob koncu pogodbe, kot so vračilo ali uničenje podatkov, vračilo sredstev in deaktivacija računov.

Zaključi, da je kontrolni ukrep 5.20 »vaša zadnja vzvodna točka« in »sodi na nabavno kontrolno točko«. Ko je pogodba podpisana, se pogajalski vzvod zmanjša. Pred podpisom se lahko dokazila in obveznosti določijo kot pogoji nakupa.

Za zunanji razvoj faza Controls in Action, korak 21, kontrolni ukrep 8.30, dodaja še eno nabavno zahtevo. Blueprint navaja:

V jedru tega kontrolnega ukrepa je načelo, da mora biti varnost pogodbena zahteva, ne ustno pričakovanje.

Zunanje ekipe morajo izpolnjevati enake standarde varnega razvoja kot notranje ekipe, vključno s statično analizo, strokovnim medsebojnim pregledom, šifriranjem, MFA do repozitorijev ter vidnostjo v kodo, arhitekturne odločitve, ranljivosti, zahtevke za spremembe, dnevnike CI/CD in rezultate skeniranja.

Zgradite kontrolno točko RFP z varnostjo kot predpogojem v enem popoldnevu

Predpostavimo, da vaša organizacija želi platformo za analitiko strank. Zajemala bo identifikatorje strank, vedenjske dogodke, metapodatke podpore in reference transakcij. Lastnik poslovnega procesa želi hitro odobritev. Ekipa za varnost ima en teden.

Začnite z zapisom nabavne kontrolne točke ter kot izvorne dokumente uporabite Politiko varnosti tretjih oseb in dobaviteljev, Politiko zahtev za varnost aplikacij, Politiko uporabe storitev v oblaku, Politiko pravne in regulativne skladnosti in korak 23 Zenith Blueprint.

RFP priložite vprašalnik za varnost kot predpogoj. Izogibajte se splošnim vprašanjem, kot je »Ali šifrirate podatke?«. Postavite vprašanja, usmerjena v dokazila:

1. Predložite svoje aktualno neodvisno poročilo o zagotovilih, certifikat ali enakovredna dokazila o kontrolah.
2. Opredelite lokacije gostovanja, možnosti lokacije hrambe podatkov, lokacije varnostnih kopij in lokacije dostopa do podpore.
3. Predložite DPA, seznam podobdelovalcev in postopek obveščanja o spremembah podobdelovalcev.
4. Potrdite roke za obveščanje o incidentih, vključno s podporo za 24-urno zgodnje opozorilo, kadar se lahko sprožijo delovni tokovi NIS2, in podporo postopnemu poročanju za stranke, regulirane po DORA.
5. Predložite politiko razkritja ranljivosti, SLA za popravke po resnosti in dokazila o nedavnem upravljanju odprave ranljivosti.
6. Predložite dokazila o varnosti produkta, kot so opis življenjskega cikla varnega razvoja, povzetek penetracijskega testiranja, SBOM ali izjava o preglednosti komponent ter obdobje podpore varnostnim posodobitvam.
7. Potrdite MFA, načelo najmanjših privilegijev, beleženje, spremljanje administratorskega dostopa in pravice stranke do presoje ali zahtev za dokazila.
8. Opišite izvoz, izbris, vračilo, podporo pri prenehanju in prehodno pomoč.
9. Navedite bistvene podizvajalce in odvisnosti IKT, ki podpirajo storitev.
10. Potrdite, ali se podatki strank uporabljajo za usposabljanje, analitiko, izboljšave produkta ali razvoj modelov umetne inteligence, ter opredelite pravno podlago ali model navodil obdelovalcu.

Nato ocenite dobavitelja pred pogajanji.

Na koncu posodobite register tveganj in izjavo o uporabnosti. Zapis o obravnavi tveganja mora pokazati, zakaj se uporabljajo kontrolni ukrepi ISO/IEC 27002:2022 5.19, 5.20 in 5.21, katere pogodbene in tehnične zahteve so bile izbrane, kdo je lastnik preostalega tveganja in kakšna pogostost spremljanja velja. Če želi poslovna stran kljub vrzelim nadaljevati, uporabite formalni zapis o sprejemu tveganja z datumom izteka, kompenzacijskimi kontrolnimi ukrepi in odobritvijo izvršnega vodstva.

Pogodbene klavzule, ki predpise pretvorijo v izvršljive obveznosti

Varnostna pričakovanja morajo postati pogodbene zaveze. Certifikat je lahko koristen, vendar redko odgovori na vsa vprašanja o vaši konkretni storitvi, lokaciji podatkov, podizvajalcih, modelu podpore, zavezah glede incidentov ali izstopnih pravicah.

Ta tabela je praktičen most med pravnimi obveznostmi in nabavnim delom. Pravni službi, varnosti in nabavi pomaga tudi pri pogajanjih iz istega osnovnega nabora kontrolnih ukrepov.

Preslikava navzkrižne skladnosti: ena datoteka dobavitelja, številne obveznosti

Prednost uporabe ISO/IEC 27001:2022 kot hrbtenice je, da lahko ena datoteka zagotovil o dobavitelju podpira več regulativnih pogovorov.

NIST CSF 2.0 je uporaben kot komunikacijska plast. Njegova funkcija GOVERN poudarja zavedanje o pravnih, regulativnih, pogodbenih, zasebnostnih in odvisnostnih vidikih. Njegovi rezultati GV.SC za dobavno verigo zahtevajo procese upravljanja tveganj dobavne verige, vloge dobaviteljev, prednostno razvrščanje dobaviteljev po kritičnosti, pogodbene zahteve, skrbni pregled, spremljanje, načrtovanje incidentov in načrtovanje prenehanja.

To se jasno preslika na korak 23 Zenith Blueprint in kontrolne ukrepe ISO/IEC 27002:2022 5.19 do 5.21, kot so preslikani v Zenith Controls. Upravnim odborom daje tudi jezik, ki ga razumejo: trenutno stanje, ciljno stanje, vrzel, tveganje, ukrep, lastnik in datum.

Kaj bodo vprašali presojevalci

Močan proces nabave z varnostjo kot predpogojem mora prestati različne revizijske poglede.

Presojevalec ISO/IEC 27001:2022 bo začel s kontekstom in obsegom ISMS. Vprašal bo, ali so v obseg vključeni vmesniki in odvisnosti dobaviteljev, ali zahteve zainteresiranih strani vključujejo NIS2, DORA, GDPR in pogodbe s strankami ter ali se tveganja dobaviteljev dosledno ocenjujejo po metodologiji tveganj. Sledil bo poti v obravnavo tveganj, izjavo o uporabnosti, dobaviteljske kontrolne ukrepe, operativna dokazila, notranjo presojo in vodstveni pregled.

Pregledovalec DORA se bo osredotočil na poslovne funkcije, podprte z IKT, kritične ali pomembne funkcije, zapise odvisnosti od tretjih oseb, pogodbene klavzule, pravice do presoje in dostopa, sodelovanje pri incidentih, testiranje odpornosti, izstopne strategije in tveganje koncentracije. Če SaaS podpira kritično ali pomembno funkcijo, lahek vprašalnik za dobavitelja ne bo zadostoval.

Organ NIS2 bo vprašal, kako je organizacija ocenila prakse kibernetske varnosti dobaviteljev, ranljivosti neposrednih dobaviteljev, podporo pri obveščanju o incidentih, odvisnosti neprekinjenosti in odločitve o varni pridobitvi. Preveril bo, ali zagotovila o dobaviteljih podpirajo lastne obveznosti organizacije po Article 21 in Article 23.

Pregledovalec GDPR bo vprašal, ali so bile vloge upravljavca in obdelovalca razumljene pred začetkom obdelave, ali so bili DPA ali enakovredni pogoji dogovorjeni pred deljenjem podatkov, ali so bili podobdelovalci razkriti, ali so bili varnostni ukrepi ustrezni, ali je sodelovanje ob kršitvah pogodbeno urejeno in ali je vračilo ali izbris podatkov izvršljiv.

Presojevalec v slogu COBIT 2019 ali ISACA se bo osredotočil na upravljanje in odgovornost: kdo je odobril dobavitelja, katero tveganje je bilo sprejeto, ali so bile zahteve politike upoštevane, ali se izjeme spremljajo ter ali so bile koristi, tveganja in viri uravnoteženi.

Vaš paket dokazil mora vključevati razvrstitev dobavitelja, odobritev lastnika poslovnega procesa, oceno tveganja, varnostne zahteve RFP, odgovore dobavitelja, DPA, varnostno prilogo, SLA, pravice do presoje, register podobdelovalcev, zaveze glede ranljivosti, klavzule o incidentih, dokazila o lokaciji v oblaku, dokazila o beleženju in šifriranju, izstopne pogoje, zapise ponovnih ocen, izjeme in preslikavo izjave o uporabnosti.

Pogosti vzorci neuspeha pri nakupu programske opreme

Prvi neuspeh je obravnava nabave kot komercialnega delovnega toka in varnosti kot tehničnega delovnega toka. Ko varnost prejme pogodbo, je poslovna stran že psihološko zavezana, datum implementacije je objavljen in pogajalski vzvod je šibek.

Drugi neuspeh je nadomeščanje dokazil. Dobavitelj predloži certifikat, kupec pa domneva, da odgovori na vsako vprašanje. Certifikacija lahko pomaga, vendar morda ne pokriva točno določenega produkta, regije gostovanja, modela podpore, verige podizvajalcev, obveznosti glede incidentov, uporabe podatkov za umetno inteligenco ali izstopnih zahtev.

Tretji neuspeh je spregledano tveganje v nižjih členih verige. Dobavitelj SaaS se lahko zanaša na gostovanje v oblaku, analitična orodja, platforme za podporo, razvojne ekipe v tujini, ponudnike modelov umetne inteligence in obdelovalce plačil. Kontrolni ukrep ISO/IEC 27002:2022 5.21 zahteva pozornost do dobavne verige IKT za neposrednim dobaviteljem. Po DORA se to povezuje s podizvajanjem in tveganjem koncentracije. Po GDPR se povezuje s podobdelovalci. Po NIS2 se povezuje z ranljivostmi neposrednih dobaviteljev in praksami kibernetske varnosti dobaviteljev.

Četrti neuspeh je šibko besedilo o incidentih. Pogodba, ki pravi, da bo »dobavitelj stranko obvestil nemudoma«, morda ne podpira zgodnjega opozorila po NIS2, postopnega poročanja po DORA, komunikacije s strankami ali notranje eskalacije. Klavzule o incidentih potrebujejo časovne okvire, sprožilce, kontakte, obveznosti sodelovanja in obveznosti glede dokazil.

Peti neuspeh so nejasne izstopne pravice. Če dobavitelj postane nevaren, neskladen, prevzet, insolventen ali strateško neustrezen, kupec potrebuje izvoz, izbris, podporo pri prehodu, deaktivacijo računov in dokazila o uničenju. Izstop ni pravna naknadna misel. Je kontrolni ukrep odpornosti.

Od nabavne kontrolne točke do živih zagotovil o dobaviteljih

Nabava z varnostjo kot predpogojem se ne konča ob podpisu. Zrel dobaviteljski življenjski cikel v slogu Clarysec ima pet stopenj.

Za dobavitelje z visokim tveganjem mora spremljanje vključevati osveževanje dokazil, sestanke za varnostni pregled, sodelovanje v namiznih vajah incidentov, pregled dostopov, poročanje o ranljivostih in popravkih, pregled sprememb storitev in posodobitve podobdelovalcev. Za dobavitelje z nižjim tveganjem lahko zadostuje letni pregled. Razširljivost ISO 27001, sorazmernost NIS2 in sorazmernost DORA podpirajo prilagajanje, vendar mora biti prilagajanje utemeljeno in dokumentirano.

Naslednji korak s Clarysec

Naslednji tvegani nakup SaaS ne bo čakal na popolno prenovo upravljanja. Začnite pri naslednji nabavni zahtevi.

Uporabite Zenith Blueprint: 30-koračni načrt presojevalca za implementacijo kontrolnih ukrepov odnosov z dobavitelji iz koraka 23 in kontrolnih ukrepov zunanjega razvoja iz koraka 21. Uporabite Zenith Controls za preslikavo kontrolnih ukrepov ISO/IEC 27002:2022 5.19, 5.20 in 5.21 čez NIS2, DORA, GDPR, NIST CSF 2.0 in revizijska pričakovanja, usmerjena v COBIT. Uporabite knjižnico politik Clarysec, vključno s Politiko varnosti tretjih oseb in dobaviteljev, Politiko zahtev za varnost aplikacij, Politiko uporabe storitev v oblaku in Politiko pravne in regulativne skladnosti, da kontrolno točko naredite izvršljivo.

Pred podpisom naslednje pogodbe zahtevajte razvrstitev dobavitelja, varnostna dokazila, pripravljenost DPA, zaveze glede incidentov, obravnavo ranljivosti, preglednost podizvajalcev, pravice do presoje in izstopne pogoje.

To je nabava z varnostjo kot predpogojem. Tako vodje informacijske varnosti regulativni pritisk pretvorijo v nabavno moč. Tako vodje skladnosti prekrivajoče se obveznosti pretvorijo v eno datoteko dokazil. Tako presojevalci vidijo, da je bilo tveganje dobavitelja obravnavano, preden je nastala odvisnost. In tako lastniki poslovnih procesov kupujejo programsko opremo hitreje, ne da bi prevzeli neupravljano tveganje.

Ste pripravljeni svoj naslednji nakup programske opreme pretvoriti v kontrolni ukrep, pripravljen za presojo? Raziščite integrirani nabor politik Clarysec, prenesite Zenith Blueprint, preglejte Zenith Controls ali se dogovorite za predstavitev, da zgradite program nabave z varnostjo kot predpogojem, ki vzdrži NIS2, DORA, GDPR, pričakovanja CRA in dejansko presojo.