Nabava softvera uvjetovana sigurnošću u 2026.

Utorak je ujutro početkom 2026., a Maria, CISO brzo rastuće europske platne kompanije, izlaže upravnom odboru. Posljednja točka dnevnog reda trebala bi biti rutinska: odobrenje nove platforme za otkrivanje prijevara potpomognute umjetnom inteligencijom. Dobavljač ima dojmljivu demonstraciju, vremenski ograničen popust, sigurnosni pregled na jednoj stranici i standardni ugovor.

Tada počinju pitanja.

Glavni izvršni direktor pita: “Kako znamo da je ova platforma sigurna? Naši klijenti iz financijskih usluga traže dokaze o usklađenosti s DORA, a ovaj dobavljač postaje dio naše kritične infrastrukture.”

Pravni odjel pita je li Ugovor o obradi podataka spreman, gdje će se obrađivati podaci klijenata iz EU-a i jesu li podizvršitelji obrade objavljeni. Voditelj operativne otpornosti pita za planiranje izlaska, izvoze sigurnosnih kopija i neprekidnost za kritične funkcije. Inženjer za sigurnost proizvoda traži objavu ranjivosti, dokaze o zakrpavanju i SBOM ili ekvivalentnu izjavu o transparentnosti komponenti. Nabava postavlja pitanje zbog kojeg rizik dobavljača postaje skup: “Možemo li odobriti sada, a dokumentaciju prikupiti nakon potpisa?”

To je trenutak u kojem moderna nabava softvera ili postaje kontrola ili postaje buduće izvješće o incidentu.

U 2026. sigurna nabava softvera ne može se oslanjati na dobru volju nakon sklapanja ugovora. Sigurnost opskrbnog lanca prema NIS2, IKT rizik trećih strana prema DORA, odgovornost izvršitelja obrade prema GDPR-u i očekivanja sigurnosti proizvoda prema Aktu o kibernetičkoj otpornosti premjestili su osiguranje dobavljača na točku donošenja odluke o nabavi. Kupcima je potrebna nabava softvera uvjetovana sigurnošću, u kojoj korisnik definira sigurnosne dokaze, ugovorne odredbe, kontrolne točke uvođenja i operativne odgovornosti prije kupnje.

Za klijente Clarysec-a odgovor nije još jedna proračunska tablica koja nestaje u e-pošti. To je sustav kontrola nabave usklađen s ISO/IEC 27001:2022, mapiran kroz Clarysec politike, Zenith Blueprint: revizorov plan u 30 koraka i Zenith Controls, tako da svaka kupnja softvera ili SaaS-a ima dokaziv trag od poslovne potrebe do odluke o riziku dobavljača.

Sigurnost kao uvjet nabave nova je kontrola nabave softvera

O ugrađenoj sigurnosti obično se govori sa strane dobavljača. Sigurnost kao uvjet nabave disciplina je na strani kupca: organizacija odbija kupiti softver ako dobavljač ne može dokazati da su sigurnost, privatnost, otpornost, postupanje s ranjivostima i revizibilnost ugrađeni u ponudu.

Time se mijenja razgovor o kupnji. Umjesto pitanja: “Imate li sigurnost?”, nabava postavlja preciznija pitanja:

• Koje ćete podatke obrađivati, gdje i u kojoj pravnoj ulozi?
• O kojoj će poslovnoj funkciji ovisiti vaša usluga i koliko je ona kritična?
• Koji dokazi potvrđuju da vaše kontrole djeluju, a ne samo da su dokumentirane?
• Na koje ćete se rokove za obavješćivanje o incidentima obvezati?
• Koje dokaze o objavi ranjivosti, zakrpavanju, SBOM-u ili VEX-u možete dostaviti?
• Koji će podizvođači ili podizvršitelji obrade imati doticaj s našim podacima ili uslugom?
• Možemo li tijekom trajanja ugovora provoditi reviziju, inspekciju ili zahtijevati dokaze?
• Što se događa pri raskidu, migraciji, povredi, insolventnosti ili upitu regulatornog tijela?

ISO/IEC 27001:2022 daje upravljačku okosnicu za ovaj pomak. Točka 4 zahtijeva da organizacija razumije kontekst, zainteresirane strane i opseg ISMS-a, uključujući vanjske regulatorne i dobavljačke zahtjeve. Točka 5 pretvara rizik dobavljača u odgovornost vodstva i upravljanja. Točka 6 zahtijeva procjenu rizika, obradu rizika, odabir kontrola, Izjavu o primjenjivosti i odluke o preostalom riziku. Točka 8 zahtijeva kontrolirano izvođenje procesa, uključujući procese koje pružaju vanjske strane. Točka 9 zahtijeva praćenje, unutarnju reviziju i preispitivanje od strane uprave.

To znači da nabava softvera nije samo komercijalni radni tok. Ona postaje operativni i revizijski provjerljiv proces ISMS-a. Regulatori i revizori sve češće pitaju zašto je organizacija prihvatila dobavljača prije nego što je razumjela rizik. Nabava uvjetovana sigurnošću daje jasan odgovor: rizik je procijenjen, obrađen, ugovorno uređen i dodijeljen prije nastanka ovisnosti.

Zašto se NIS2, DORA, GDPR i CRA susreću pri odabiru dobavljača

Marijin upravni odbor postavlja prava pitanja jer jedan dobavljač softvera može istodobno aktivirati više obveza.

NIS2 se primjenjuje prema sektoru, veličini i kritičnosti, pri čemu Annex I i Annex II u opseg uključuju mnoge digitalne, financijske, infrastrukturne, upravljane uslužne i o oblaku ovisne organizacije. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući sigurnost opskrbnog lanca, sigurnu nabavu, siguran razvoj i održavanje, postupanje s ranjivostima, kontrolu pristupa, upravljanje imovinom, neprekidnost, postupanje s incidentima i procjenu djelotvornosti kontrola. Article 21(3) posebno zahtijeva obraćanje pozornosti na ranjivosti izravnih dobavljača i prakse dobavljača u području kibernetičke sigurnosti. Article 23 uspostavlja očekivanja za fazno prijavljivanje značajnih incidenata, uključujući rano upozorenje u roku od 24 sata i obavijest u roku od 72 sata.

DORA se primjenjuje od 17. siječnja 2025. na financijske subjekte u opsegu. Uspostavlja jedinstvene zahtjeve za upravljanje IKT rizicima, prijavljivanje incidenata povezanih s IKT-om, testiranje digitalne operativne otpornosti i upravljanje IKT rizicima trećih strana. DORA je osobito preskriptivna za nabavu. Financijski subjekti trebaju strategije za IKT rizike trećih strana, registre aranžmana za IKT usluge, dubinsku analizu dobavljača, analizu rizika koncentracije, pisane ugovore s odredbama o sigurnosti i otpornosti, prava na reviziju i pristup, obveze suradnje, prava raskida i planove izlaska. Articles 28 and 30 središnji su za IKT rizik trećih strana i ugovorne kontrole, dok Articles 17 to 23 oblikuju upravljanje incidentima i izvješćivanje.

GDPR dodaje kontrolnu točku odgovornosti izvršitelja obrade. Articles 5, 28, 32, 33 and 34 zahtijevaju odgovornost, ugovore s izvršiteljima obrade, odgovarajuću sigurnost, suradnju pri obavješćivanju o povredi i postupanje s učinkom na ispitanike. SaaS dobavljač koji obrađuje osobne podatke nije samo dobavljač. On postaje dio profila usklađenosti voditelja obrade. DPA, tehničke i organizacijske mjere, popis podizvršitelja obrade, zaštitne mjere za prijenos, pravila zadržavanja i obveze brisanja moraju biti jasni prije početka obrade.

CRA očekivanja dodaju osiguranje proizvoda. Čak i kada kupac nije proizvođač, timovi nabave trebaju zahtijevati dokaze o sigurnom razvoju, postupanju s ranjivostima, podršci za proizvod, sigurnosnim ažuriranjima, koordiniranoj objavi ranjivosti i transparentnosti komponenti, primjerice SBOM ili ekvivalentnu izjavu. Ti zahtjevi pripadaju u RFP-ove, sigurnosne priloge i kriterije prihvata.

Zajednička je poruka jednostavna: organizacija koja kupuje mora znati što kupuje, koji rizik unosi i koje dokaze može proizvesti kada to zatraže regulatori, klijenti ili revizori.

ISO 27001 okosnica kontrola za osiguranje dobavljača

Najučinkovitiji model nabave uvjetovane sigurnošću nije model po pojedinoj regulativi. On je najprije utemeljen na kontrolama. Clarysec koristi ISO/IEC 27001:2022 kao okosnicu ISMS-a, uz smjernice za kontrole ISO/IEC 27002:2022 i mapiranje međusobne usklađenosti u Zenith Controls.

U Zenith Controls, osiguranje dobavljača usidreno je oko kontrola ISO/IEC 27002:2022 5.19, 5.20 i 5.21. To nisu izolirane stavke kontrolnog popisa. One čine životni ciklus nabave.

Zenith Controls mapira ove ISO kontrole na regulatorna i revizijska očekivanja. Ne stvara zasebne vlasničke kontrole nazvane Zenith Controls. Pomaže timovima razumjeti kako kontrole ISO/IEC 27002:2022 podupiru NIS2, DORA, GDPR, NIST CSF 2.0 i osiguranje usmjereno na COBIT.

Važna je i prateća mreža kontrola. Osiguranje dobavljača povezano je s upravljanjem imovinom, kontrolom pristupa, sigurnošću oblaka, upravljanjem ranjivostima, zapisivanjem događaja, upravljanjem incidentima, IKT spremnošću za neprekidnost poslovanja, sigurnim razvojem, sigurnošću aplikacija, upravljanjem konfiguracijom, sigurnosnim kopiranjem, redundancijom, pravnom usklađenošću, privatnošću, upravljanjem promjenama i neovisnim pregledom. Nabava koordinira proces, ali vlasništvo nad rizikom mora uključivati vlasnika poslovanja, informacijsku sigurnost, pravne poslove, privatnost, IT, financije i vlasnika usluge.

Clarysec kontrolne točke politika prije potpisa

Clarysecov model politika namjerno premješta osiguranje dobavljača uzvodno. Najsnažniji zahtjevi nalaze se ondje gdje pripadaju: prije potpisivanja ugovora, prije aktivacije pretplata na oblak i prije dijeljenja podataka.

SME verzija Clarysecove Politike sigurnosti trećih strana i dobavljača navodi:

Procijenite i dokumentirajte rizike dobavljača prije potpisivanja ugovora ili dodjele pristupa.

To dolazi iz odjeljka “Ciljevi”, točke politike 3.3. Odredba je kratka jer je namjera kontrole nedvojbena: nema procjene rizika, nema ugovora, nema pristupa.

Za poslovna okruženja, Clarysecova Politika sigurnosti trećih strana i dobavljača učvršćuje pred-ugovornu kontrolnu točku:

Svi novi dobavljači moraju proći dokumentiranu sigurnosnu procjenu prije sklapanja ugovora.

To dolazi iz odjeljka “Zahtjevi za provedbu politike”, točke politike 6.1.1. Ista politika također navodi “prava na reviziju, inspekciju i zahtjev za sigurnosnim dokazima” u odjeljku “Zahtjevi upravljanja”, točki politike 5.3.4.

Za kupnju oblaka i SaaS-a, SME Politika korištenja usluga u oblaku dodaje praktičnu kontrolnu točku odobrenja:

Sva uporaba usluga u oblaku mora biti pregledana i odobrena od strane glavnog direktora (GM) prije implementacije ili pretplate.

To dolazi iz odjeljka “Zahtjevi upravljanja”, točke politike 5.1. U maloj organizaciji to odobrenje može biti ekvivalent odboru za upravljanje oblakom. U poduzeću ono postaje radni tok kroz nabavu, sigurnost, privatnost i arhitekturu. Poslovna Politika korištenja usluga u oblaku također podupire ugovorne zahtjeve za oblak, uključujući provedive odredbe u ugovorima s CSP-ovima.

Za nabavu softvera, poslovna Politika zahtjeva sigurnosti aplikacija izričita je:

Nabava softvera ili aranžmani izdvajanja vanjskim izvođačima moraju uključivati sigurnosne zahtjeve u RFP-ovima, ugovorima i SLA-ovima, uključujući odredbe o rokovima otklanjanja ranjivosti i pravima trećih strana na reviziju.

To dolazi iz odjeljka “Zahtjevi upravljanja”, točke politike 5.4. Obratite pozornost na redoslijed: RFP-ovi, ugovori i SLA-ovi. Sigurnost se pojavljuje u fazi tržišnog angažmana, a ne kao prilog nakon dodjele.

Za nabavu vođenu GDPR-om, Clarysecova SME Politika pravne i regulatorne usklađenosti zahtijeva:

Klauzule Ugovora o obradi podataka (DPA) ili ekvivalentne ugovorne odredbe moraju biti dogovorene prije dijeljenja bilo kakvih osobnih ili osjetljivih podataka.

To dolazi iz odjeljka “Zahtjevi za provedbu politike”, točke politike 6.3.2. Time se sprječava jedan od najčešćih propusta pri uvođenju SaaS-a: prijenos osobnih podataka u alat prije nego što su dogovoreni uvjeti izvršitelja obrade, obveze u slučaju povrede i uvjeti za podizvršitelje obrade.

Za sigurnost aplikacija dobavljača, SME Politika zahtjeva sigurnosti aplikacija zahtijeva da nabava:

specificira obveze za objavu ranjivosti, rokove odgovora i zakrpavanje.

To je iz odjeljka “Zahtjevi upravljanja”, točke politike 5.3.2. Također navodi:

GM mora zatražiti dokumentaciju ili certifikacije (npr. SOC 2, ISO 27001, izvješća o sigurnosnom testiranju) kao dokaz usklađenosti dobavljača, gdje je primjenjivo.

To dolazi iz odjeljka “Zahtjevi za provedbu politike”, točke politike 6.3.2. Ključna riječ je dokaz. Nabava uvjetovana sigurnošću ne temelji se na izjavama o povjerenju. Temelji se na artefaktima koji se mogu pregledati.

Nabavna kontrolna točka u Zenith Blueprint

Zenith Blueprint tretira sigurnost dobavljača kao operativnu kontrolu, a ne kao nabavnu parolu. U fazi Controls in Action, Step 23 obuhvaća organizacijske kontrole 5.19 do 5.37, uključujući informacijsku sigurnost u odnosima s dobavljačima.

Blueprint objašnjava:

Počinje s klasifikacijom dobavljača. Ne nose svi dobavljači isti rizik. Usluga čišćenja može imati fizički pristup uredima, ali ne i mrežama. Tvrtka za penetracijsko testiranje ili pružatelj usluga hostinga u oblaku, s druge strane, može imati dubok tehnički pristup samoj jezgri vaše infrastrukture. Klasifikacija treba razmotriti obrađuje li dobavljač izravno vaše informacije ili postupa s njima, pruža li infrastrukturu ili platforme na kojima poslujete, upravlja li sustavima ili ih održava u vaše ime te može li njegova kompromitacija utjecati na vaše ciljeve povjerljivosti, cjelovitosti ili dostupnosti.

Za kontrolu 5.20, Blueprint je izravan:

Ključna područja koja se tipično uređuju ugovorima s dobavljačima uključuju obveze povjerljivosti; odgovornosti za kontrolu pristupa; tehničke i organizacijske mjere za zaštitu podataka, šifriranje, siguran prijenos, sigurnosno kopiranje i obveze dostupnosti; rokove i protokole prijavljivanja incidenata; pravo na reviziju, uključujući učestalost, opseg i pristup relevantnim dokazima; kontrole podizvođača; te odredbe na kraju ugovora, kao što su povrat ili uništenje podataka, oporavak imovine i deaktivacija računa.

Zaključuje da je kontrola 5.20 “vaša posljednja poluga utjecaja” i da “pripada na nabavnu kontrolnu točku”. Nakon potpisa ugovora, pregovaračka poluga slabi. Prije potpisa, dokazi i obveze mogu se postaviti kao uvjeti kupnje.

Za razvoj povjeren vanjskim izvođačima, faza Controls in Action, Step 21, kontrola 8.30, dodaje još jedan nabavni zahtjev. Blueprint navodi:

U središtu ove kontrole nalazi se načelo da sigurnost mora biti ugovorni zahtjev, a ne usmeno očekivanje.

Vanjski timovi trebaju ispunjavati iste standarde sigurnog razvoja kao interni timovi, uključujući statičku analizu, vršnjački pregled, šifriranje, MFA za repozitorije i vidljivost u kod, arhitekturne odluke, ranjivosti, zahtjeve za promjenu, CI/CD dnevnike i rezultate skeniranja.

Izgradite RFP kontrolnu točku sa sigurnošću kao uvjetom u jednom poslijepodnevu

Pretpostavimo da vaša organizacija želi platformu za analitiku klijenata. Ona će unositi identifikatore klijenata, događaje ponašanja, metapodatke podrške i reference transakcija. Vlasnik poslovanja želi brzo odobrenje. Sigurnosni tim ima jedan tjedan.

Počnite sa zapisom nabavne kontrolne točke koristeći Politiku sigurnosti trećih strana i dobavljača, Politiku zahtjeva sigurnosti aplikacija, Politiku korištenja usluga u oblaku, Politiku pravne i regulatorne usklađenosti i Step 23 iz Zenith Blueprint kao izvorne dokumente.

Priložite RFP-u upitnik za sigurnost kao uvjet nabave. Izbjegavajte generička pitanja poput “Šifrirate li podatke?” Postavljajte pitanja vođena dokazima:

1. Dostavite aktualno neovisno izvješće o sigurnosnom osiguranju, certifikat ili ekvivalentne dokaze o kontrolama.
2. Navedite lokacije hostinga, mogućnosti rezidentnosti podataka, lokacije sigurnosnih kopija i lokacije pristupa podrške.
3. Dostavite DPA, popis podizvršitelja obrade i postupak obavješćivanja o promjenama podizvršitelja obrade.
4. Potvrdite rokove obavješćivanja o incidentima, uključujući podršku za rano upozorenje u roku od 24 sata kada se mogu pokrenuti NIS2 radni tokovi i podršku faznom izvješćivanju za korisnike regulirane DORA-om.
5. Dostavite politiku objave ranjivosti, SLA-ove za zakrpe prema ozbiljnosti i dokaze o nedavnom upravljanju otklanjanjem ranjivosti.
6. Dostavite dokaze o sigurnosti proizvoda, kao što su opis životnog ciklusa sigurnog razvoja, sažetak penetracijskog testiranja, SBOM ili izjava o transparentnosti komponenti te razdoblje podrške za sigurnosna ažuriranja.
7. Potvrdite MFA, načelo najmanjih ovlasti, zapisivanje događaja, praćenje administratorskog pristupa i prava korisnika na reviziju ili zahtjev za dokazima.
8. Opišite izvoz, brisanje, povrat, podršku pri raskidu i pomoć pri tranziciji.
9. Navedite značajne podizvođače i IKT ovisnosti koje podupiru uslugu.
10. Potvrdite koriste li se podaci klijenata za obuku, analitiku, poboljšanje proizvoda ili razvoj AI modela te navedite pravnu osnovu ili model uputa izvršitelju obrade.

Zatim ocijenite dobavljača prije pregovora.

Na kraju ažurirajte registar rizika i Izjavu o primjenjivosti. Zapis obrade rizika treba pokazati zašto se primjenjuju kontrole ISO/IEC 27002:2022 5.19, 5.20 i 5.21, koji su ugovorni i tehnički zahtjevi odabrani, tko je vlasnik preostalog rizika i koji se ritam praćenja primjenjuje. Ako poslovanje želi nastaviti unatoč prazninama, upotrijebite formalni zapis prihvaćanja rizika s datumom isteka, kompenzacijskim kontrolama i odobrenjem izvršnog rukovodstva.

Ugovorne odredbe koje regulativu pretvaraju u provedive obveze

Sigurnosna očekivanja moraju postati ugovorne obveze. Certifikat može biti koristan, ali rijetko odgovara na svako pitanje o vašoj konkretnoj usluzi, lokaciji podataka, podizvođačima, modelu podrške, obvezama u vezi s incidentima ili pravima izlaska.

Ova tablica praktičan je most između pravnih obveza i rada nabave. Također pomaže pravnom odjelu, sigurnosti i nabavi da pregovaraju s iste polazne osnove kontrola.

Mapiranje međusobne usklađenosti: jedna datoteka dobavljača, mnogo obveza

Prednost korištenja ISO/IEC 27001:2022 kao okosnice jest u tome što jedna datoteka osiguranja dobavljača može poduprijeti više regulatornih razgovora.

NIST CSF 2.0 koristan je kao komunikacijski sloj. Njegova funkcija GOVERN naglašava svijest o pravnim, regulatornim, ugovornim, privatnosnim i ovisnosnim zahtjevima. Njegovi ishodi GV.SC za opskrbni lanac zahtijevaju procese upravljanja rizicima opskrbnog lanca, uloge dobavljača, prioritizaciju dobavljača prema kritičnosti, ugovorne zahtjeve, dubinsku analizu dobavljača, praćenje, planiranje incidenata i planiranje raskida.

To se jasno mapira na Step 23 iz Zenith Blueprint i kontrole ISO/IEC 27002:2022 5.19 do 5.21 kako su mapirane u Zenith Controls. Upravnim odborima daje i jezik koji razumiju: trenutačno stanje, ciljno stanje, praznina, rizik, radnja, vlasnik i datum.

Što će revizori pitati

Snažan proces nabave uvjetovane sigurnošću treba izdržati različite revizijske perspektive.

Revizor ISO/IEC 27001:2022 počet će s kontekstom i opsegom ISMS-a. Pitat će jesu li sučelja i ovisnosti dobavljača uključeni, obuhvaćaju li zahtjevi zainteresiranih strana NIS2, DORA, GDPR i ugovore s klijentima te procjenjuju li se rizici dobavljača dosljedno prema metodologiji rizika. Pratit će trag kroz obradu rizika, Izjavu o primjenjivosti, kontrole dobavljača, operativne dokaze, unutarnju reviziju i preispitivanje od strane uprave.

Pregledavatelj za DORA usredotočit će se na poslovne funkcije podržane IKT-om, kritične ili važne funkcije, zapise o ovisnostima o trećim stranama, ugovorne odredbe, prava na reviziju i pristup, suradnju pri incidentima, testiranje otpornosti, strategije izlaska i rizik koncentracije. Ako SaaS podupire kritičnu ili važnu funkciju, lagani upitnik dobavljača neće biti dovoljan.

Tijelo nadležno za NIS2 pitat će kako je organizacija procijenila prakse dobavljača u području kibernetičke sigurnosti, ranjivosti izravnih dobavljača, podršku za obavješćivanje o incidentima, ovisnosti neprekidnosti i odluke o sigurnoj nabavi. Provjerit će podupire li osiguranje dobavljača vlastite obveze organizacije prema Article 21 i Article 23.

Pregledavatelj za GDPR pitat će jesu li uloge voditelja obrade i izvršitelja obrade bile jasne prije početka obrade, jesu li DPA ili ekvivalentni uvjeti dogovoreni prije dijeljenja podataka, jesu li podizvršitelji obrade objavljeni, jesu li sigurnosne mjere odgovarajuće, je li suradnja pri povredi ugovorno uređena i jesu li povrat ili brisanje podataka provedivi.

Revizor u stilu COBIT 2019 ili ISACA usredotočit će se na upravljanje i odgovornost: tko je odobrio dobavljača, koji je rizik prihvaćen, jesu li zahtjevi politike poštovani, prate li se iznimke i jesu li koristi, rizik i resursi uravnoteženi.

Vaš paket dokaza treba uključivati klasifikaciju dobavljača, odobrenje vlasnika poslovanja, procjenu rizika, sigurnosne zahtjeve u RFP-u, odgovore dobavljača, DPA, sigurnosni prilog, SLA, prava na reviziju, registar podizvršitelja obrade, obveze u vezi s ranjivostima, odredbe o incidentima, dokaze o lokaciji u oblaku, dokaze o zapisivanju događaja i šifriranju, uvjete izlaska, zapise ponovne procjene, iznimke i mapiranje Izjave o primjenjivosti.

Uobičajeni obrasci neuspjeha u kupnji softvera

Prvi neuspjeh jest tretiranje nabave kao komercijalnog radnog toka, a sigurnosti kao tehničkog radnog toka. Dok sigurnost primi ugovor, poslovanje se već psihološki obvezalo, datum implementacije je objavljen, a pregovaračka poluga slaba.

Drugi neuspjeh jest zamjena dokaza. Dobavljač dostavi certifikat, a kupac pretpostavi da on odgovara na svako pitanje. Certifikacija može pomoći, ali možda ne pokriva točan proizvod, regiju hostinga, model podrške, lanac podizvođača, obveze u vezi s incidentima, uporabu AI podataka ili zahtjeve izlaska.

Treći neuspjeh jest propuštanje nizvodnog rizika. SaaS dobavljač može se oslanjati na hosting u oblaku, alate za analitiku, platforme za podršku, offshore timove za razvoj, pružatelje AI modela i procesore plaćanja. Kontrola ISO/IEC 27002:2022 5.21 zahtijeva obraćanje pozornosti na IKT opskrbni lanac iza izravnog dobavljača. Prema DORA, to se povezuje s podugovaranjem i rizikom koncentracije. Prema GDPR-u, povezuje se s podizvršiteljima obrade. Prema NIS2, povezuje se s ranjivostima izravnih dobavljača i praksama dobavljača u području kibernetičke sigurnosti.

Četvrti neuspjeh jest slabo ugovorno definiranje incidenata. Ugovor u kojem piše da će “dobavljač bez odgode obavijestiti korisnika” možda neće podržati rano upozorenje prema NIS2, fazno izvješćivanje prema DORA, komunikaciju s korisnicima ili internu eskalaciju. Odredbe o incidentima trebaju rokove, okidače, kontakte, obveze suradnje i obveze dostave dokaza.

Peti neuspjeh jesu nejasna prava izlaska. Ako dobavljač postane nesiguran, neusklađen, preuzet, insolventan ili strateški neprikladan, kupcu su potrebni izvoz, brisanje, podrška pri tranziciji, deaktivacija računa i dokaz o uništenju. Izlaz nije pravna naknadna misao. To je kontrola otpornosti.

Od nabavne kontrolne točke do živog osiguranja dobavljača

Nabava uvjetovana sigurnošću ne završava potpisom. Zreo životni ciklus dobavljača u Clarysec stilu ima pet faza.

Za dobavljače visokog rizika praćenje treba uključivati osvježavanje dokaza, sastanke za sigurnosni pregled, sudjelovanje u stolnim vježbama za incidente, pregled pristupa, izvješćivanje o ranjivostima i zakrpama, pregled promjena usluge i ažuriranja podizvršitelja obrade. Za dobavljače nižeg rizika može biti dovoljan godišnji pregled. Skalabilnost ISO 27001, razmjernost NIS2 i razmjernost DORA podržavaju prilagodbu, ali prilagodba mora biti opravdana i dokumentirana.

Sljedeći Clarysec korak

Sljedeća rizična SaaS kupnja neće čekati savršeni redizajn upravljanja. Počnite sa sljedećim zahtjevom za nabavu.

Upotrijebite Zenith Blueprint: revizorov plan u 30 koraka za implementaciju Step 23 kontrola odnosa s dobavljačima i Step 21 kontrola razvoja povjerenog vanjskim izvođačima. Upotrijebite Zenith Controls za mapiranje kontrola ISO/IEC 27002:2022 5.19, 5.20 i 5.21 na NIS2, DORA, GDPR, NIST CSF 2.0 i revizijska očekivanja usmjerena na COBIT. Upotrijebite Clarysecovu biblioteku politika, uključujući Politiku sigurnosti trećih strana i dobavljača, Politiku zahtjeva sigurnosti aplikacija, Politiku korištenja usluga u oblaku i Politiku pravne i regulatorne usklađenosti, kako biste kontrolnu točku učinili provedivom.

Prije potpisivanja sljedećeg ugovora zahtijevajte klasifikaciju dobavljača, sigurnosne dokaze, spremnost DPA-a, obveze u vezi s incidentima, postupanje s ranjivostima, transparentnost podizvođača, prava na reviziju i uvjete izlaska.

To je nabava uvjetovana sigurnošću. Tako CISO-i pretvaraju regulatorni pritisak u pregovaračku snagu. Tako rukovoditelji usklađenosti pretvaraju preklapajuće obveze u jednu datoteku dokaza. Tako revizori vide da je rizik dobavljača razmotren prije nastanka ovisnosti. I tako vlasnici poslovanja brže kupuju softver bez preuzimanja neupravljanog rizika.

Spremni ste pretvoriti sljedeću kupnju softvera u kontrolu spremnu za reviziju? Istražite Clarysecov integrirani paket politika, preuzmite Zenith Blueprint, pregledajte Zenith Controls ili zakažite demonstraciju kako biste izgradili program nabave uvjetovane sigurnošću koji može izdržati NIS2, DORA, GDPR, CRA očekivanja i stvarnu revizorsku provjeru.