Obstarávanie softvéru s bezpečnosťou ako podmienkou nákupu v roku 2026

Je utorok ráno na začiatku roka 2026 a Maria, CISO rýchlo rastúcej európskej platobnej spoločnosti, prezentuje predstavenstvu. Posledný bod programu by mal byť rutinný: schválenie novej platformy na detekciu podvodov využívajúcej AI. Dodávateľ má pôsobivé demo, časovo obmedzenú zľavu, jednostranový bezpečnostný prehľad a štandardnú zmluvu.

Potom prídu otázky.

CEO sa pýta: „Ako vieme, že táto platforma je bezpečná? Naši klienti z finančných služieb od nás žiadajú dôkazy súladu s DORA a tento dodávateľ sa stane súčasťou našej kritickej infraštruktúry.“

Právne oddelenie sa pýta, či je pripravená zmluva o spracúvaní osobných údajov, kde sa budú spracúvať údaje zákazníkov z EÚ a či sú zverejnení ďalší sprostredkovatelia. Vedúci prevádzkovej odolnosti sa pýta na plánovanie ukončenia, export záloh a kontinuitu kritických funkcií. Inžinier produktovej bezpečnosti žiada zverejňovanie zraniteľností, dôkazy o aplikácii bezpečnostných záplat a SBOM alebo rovnocenné vyhlásenie o transparentnosti komponentov. Obstarávanie položí otázku, ktorá predražuje dodávateľské riziko: „Môžeme to schváliť teraz a dokumenty zozbierať po podpise?“

To je okamih, keď sa moderné obstarávanie softvéru buď stane kontrolou, alebo budúcou správou o incidente.

V roku 2026 sa bezpečné obstarávanie softvéru nemôže spoliehať na dobrú vôľu dodávateľa po podpise zmluvy. Bezpečnosť dodávateľského reťazca podľa NIS2, riziko externých poskytovateľov IKT podľa DORA, preukázateľná zodpovednosť pri zapojení sprostredkovateľov podľa GDPR a očakávania Cyber Resilience Act v oblasti produktovej bezpečnosti presunuli dodávateľské uistenie do momentu rozhodovania o nákupe. Kupujúci potrebujú obstarávanie softvéru s bezpečnosťou ako podmienkou nákupu, pri ktorom zákazník definuje bezpečnostné dôkazy, zmluvné ustanovenia, schvaľovacie brány pre zaradenie dodávateľa a prevádzkové zodpovednosti ešte pred nákupom.

Pre klientov Clarysec nie je odpoveďou ďalší tabuľkový prehľad, ktorý zanikne v e-mailoch. Je ňou systém kontrol obstarávania zosúladený s ISO/IEC 27001:2022, mapovaný cez politiky Clarysec, Zenith Blueprint: An Auditor’s 30-Step Roadmap a Zenith Controls, aby každý nákup softvéru alebo SaaS mal obhájiteľnú stopu od potreby organizácie až po rozhodnutie o dodávateľskom riziku.

Bezpečnosť ako podmienka nákupu je novou kontrolou obstarávania softvéru

Secure-by-design sa zvyčajne rieši na strane dodávateľa. Bezpečnosť ako podmienka nákupu je disciplína na strane kupujúceho: organizácia odmieta kúpiť softvér, pokiaľ dodávateľ nedokáže preukázať, že bezpečnosť, ochrana súkromia, odolnosť, riadenie zraniteľností a auditovateľnosť sú súčasťou ponuky.

Mení sa tým nákupná diskusia. Namiesto otázky „Máte bezpečnosť?“ kladie obstarávanie presnejšie otázky:

• Aké údaje budete spracúvať, kde a v akej právnej role?
• Ktorá obchodná funkcia bude od vás závisieť a aká je jej kritickosť?
• Aké dôkazy preukazujú, že vaše kontroly fungujú, nielen že sú zdokumentované?
• K akým lehotám oznamovania incidentov sa zaviažete?
• Aké dôkazy o zverejňovaní zraniteľností, aplikácii bezpečnostných záplat, SBOM alebo VEX viete poskytnúť?
• Ktorí subdodávatelia alebo ďalší sprostredkovatelia budú mať prístup k našim údajom alebo službe?
• Môžeme počas trvania zmluvy vykonať audit, kontrolu alebo vyžiadať dôkazy?
• Čo sa stane pri ukončení, migrácii, porušení ochrany údajov, insolvencii alebo regulačnom preverení?

ISO/IEC 27001:2022 poskytuje pre túto zmenu chrbticu systému manažérstva. Kapitola 4 vyžaduje, aby organizácia pochopila svoj kontext, zainteresované strany a rozsah ISMS vrátane externých regulačných a dodávateľských požiadaviek. Kapitola 5 mení dodávateľské riziko na zodpovednosť vedenia a správy a riadenia. Kapitola 6 vyžaduje posúdenie rizík, ošetrenie rizík, výber kontrol, vyhlásenie o uplatniteľnosti a rozhodnutia o zostatkovom riziku. Kapitola 8 vyžaduje riadenú prevádzku procesov vrátane externe poskytovaných procesov. Kapitola 9 vyžaduje monitorovanie, interný audit a preskúmanie manažmentom.

To znamená, že obstarávanie softvéru nie je len komerčný pracovný postup. Stáva sa prevádzkovaným a auditovateľným procesom ISMS. Regulátori a audítori sa čoraz častejšie pýtajú, prečo organizácia akceptovala dodávateľa pred tým, ako pochopila riziko. Obstarávanie s bezpečnosťou ako podmienkou nákupu dáva jasnú odpoveď: riziko bolo posúdené, ošetrené, zmluvne podchytené a priradené ešte pred vznikom závislosti.

Prečo sa NIS2, DORA, GDPR a CRA stretávajú pri výbere dodávateľa

Predstavenstvo Márie kladie správne otázky, pretože jediný dodávateľ softvéru môže naraz spustiť viacero povinností.

NIS2 sa uplatňuje podľa sektora, veľkosti a kritickosti, pričom Annex I a Annex II zahŕňajú do rozsahu mnohé digitálne, finančné a infraštruktúrne organizácie, poskytovateľov riadených služieb a organizácie závislé od cloudu. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane bezpečnosti dodávateľského reťazca, bezpečného obstarávania, bezpečného vývoja a údržby, riadenia zraniteľností, riadenia prístupu, správy aktív, kontinuity, riadenia incidentov a posudzovania účinnosti kontrol. Article 21(3) osobitne vyžaduje pozornosť zraniteľnostiam priamych dodávateľov a kybernetickobezpečnostným praktikám dodávateľov. Article 23 vytvára očakávania postupného hlásenia významných incidentov vrátane včasného varovania do 24 hodín a oznámenia do 72 hodín.

DORA sa od 17. januára 2025 uplatňuje na finančné subjekty v rozsahu pôsobnosti. Zavádza jednotné požiadavky na riadenie rizík IKT, hlásenie incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti a riadenie rizík externých poskytovateľov IKT. DORA je pri obstarávaní obzvlášť preskriptívna. Finančné subjekty potrebujú stratégie riadenia rizík externých poskytovateľov IKT, registre zmluvných dojednaní o službách IKT, due diligence, analýzu rizika koncentrácie, písomné zmluvy s ustanoveniami o bezpečnosti a odolnosti, práva na audit a prístup, povinnosti spolupráce, práva na ukončenie a plány ukončenia. Articles 28 a 30 sú kľúčové pre riziko externých poskytovateľov IKT a zmluvné kontroly, zatiaľ čo Articles 17 až 23 formujú riadenie incidentov a hlásenie.

GDPR pridáva bránu preukázateľnej zodpovednosti pri zapojení sprostredkovateľov. Articles 5, 28, 32, 33 a 34 vyžadujú preukázateľnú zodpovednosť, zmluvy so sprostredkovateľmi, primeranú bezpečnosť, spoluprácu pri oznamovaní porušenia ochrany osobných údajov a riešenie dopadu na dotknuté osoby. Dodávateľ SaaS, ktorý spracúva osobné údaje, nie je len dodávateľ. Stáva sa súčasťou stavu súladu prevádzkovateľa. DPA, technické a organizačné opatrenia, zoznam ďalších sprostredkovateľov, primerané záruky pri prenose, pravidlá uchovávania a povinnosti výmazu musia byť známe ešte pred začiatkom spracúvania.

Očakávania CRA pridávajú uistenie o produkte. Aj keď kupujúci nie je výrobcom, tímy obstarávania majú vyžadovať dôkazy o bezpečnom vývoji, riadení zraniteľností, podpore produktu, bezpečnostných aktualizáciách, koordinovanom zverejňovaní zraniteľností a transparentnosti komponentov, napríklad SBOM alebo rovnocenné vyhlásenie. Tieto požiadavky patria do RFP, bezpečnostných príloh a akceptačných brán.

Spoločná téma je jednoduchá: nakupujúca organizácia musí vedieť, čo kupuje, aké riziko si tým prináša a aké dôkazy vie predložiť, keď sa spýtajú regulátori, zákazníci alebo audítori.

Chrbtica kontrol ISO 27001 pre dodávateľské uistenie

Najefektívnejší model obstarávania s bezpečnosťou ako podmienkou nákupu nie je postavený po jednotlivých predpisoch. Je postavený najprv na kontrolách. Clarysec používa ISO/IEC 27001:2022 ako chrbticu ISMS, podporenú usmerneniami ku kontrolám ISO/IEC 27002:2022 a mapovaním medzi režimami súladu v Zenith Controls.

V Zenith Controls je dodávateľské uistenie ukotvené okolo kontrol ISO/IEC 27002:2022 5.19, 5.20 a 5.21. Nie sú to izolované položky kontrolného zoznamu. Tvoria životný cyklus obstarávania.

Zenith Controls mapuje tieto ISO kontroly naprieč regulačnými a auditnými očakávaniami. Nevytvára samostatné proprietárne kontroly nazývané Zenith Controls. Pomáha tímom pochopiť, ako kontroly ISO/IEC 27002:2022 podporujú NIS2, DORA, GDPR, NIST CSF 2.0 a uistenie orientované na COBIT.

Dôležitá je aj podporná sieť kontrol. Dodávateľské uistenie sa prepája so správou aktív, riadením prístupu, bezpečnosťou cloudu, riadením zraniteľností, logovaním, riadením incidentov, pripravenosťou IKT na kontinuitu činností, bezpečným vývojom, bezpečnosťou aplikácií, riadením konfigurácie, zálohovaním, redundanciou, právnym súladom, ochranou súkromia, riadením zmien a nezávislým preskúmaním. Obstarávanie koordinuje proces, ale vlastníctvo rizika musí zahŕňať vlastníka obchodnej oblasti, informačnú bezpečnosť, právne záležitosti, ochranu súkromia, IT, financie a vlastníka služby.

Brány podľa politík Clarysec pred podpisom

Model politík Clarysec zámerne presúva dodávateľské uistenie proti prúdu procesu. Najsilnejšie znenie sa nachádza tam, kde patrí: pred podpisom zmlúv, pred aktiváciou cloudových predplatných a pred zdieľaním údajov.

Verzia Clarysec Politika bezpečnosti tretích strán a dodávateľov pre MSP uvádza:

Posúďte a zdokumentujte riziká dodávateľov pred podpisom zmlúv alebo udelením prístupu.

Pochádza to zo sekcie „Ciele“, bod politiky 3.3. Ustanovenie je krátke, pretože zámer kontroly je nevyjednateľný: bez posúdenia rizík nie je zmluva ani prístup.

Pre podnikové prostredia Clarysec Politika bezpečnosti tretích strán a dodávateľov posilňuje predzmluvnú bránu:

Všetci noví dodávatelia musia pred uzatvorením zmluvy absolvovať zdokumentované bezpečnostné posúdenie.

Pochádza to zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.1.1. Tá istá politika v sekcii „Požiadavky na správu a riadenie“, bod politiky 5.3.4, identifikuje aj „práva na audit, kontrolu a vyžiadanie bezpečnostných dôkazov“.

Pri nákupe cloudových služieb a SaaS pridáva verzia Politika používania cloudových služieb pre MSP praktickú schvaľovaciu bránu:

Každé používanie cloudových služieb musí pred implementáciou alebo predplatným preskúmať a schváliť generálny manažér (GM).

Pochádza to zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.1. V malej organizácii môže byť toto schválenie ekvivalentom riadiacej rady pre cloud. V podniku sa mení na pracovný postup medzi obstarávaním, bezpečnosťou, ochranou súkromia a architektúrou. Podniková Politika používania cloudových služieb podporuje aj zmluvné požiadavky pre cloud vrátane vymáhateľných ustanovení v zmluvách s poskytovateľmi cloudových služieb (CSP).

Pri obstarávaní softvéru je podniková Politika požiadaviek na bezpečnosť aplikácií explicitná:

Obstarávanie softvéru alebo outsourcingové dojednania musia zahŕňať bezpečnostné požiadavky v RFP, zmluvách a SLA vrátane ustanovení o lehotách nápravy zraniteľností a právach tretích strán na audit.

Pochádza to zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.4. Všimnite si poradie: RFP, zmluvy a SLA. Bezpečnosť sa objavuje vo fáze oslovenia trhu, nie ako príloha po pridelení zákazky.

Pri obstarávaní riadenom GDPR verzia Clarysec Politika právneho a regulačného súladu pre MSP vyžaduje:

Ustanovenia zmluvy o spracúvaní osobných údajov (DPA) alebo rovnocenné zmluvné podmienky musia byť dohodnuté pred zdieľaním akýchkoľvek osobných alebo citlivých údajov.

Pochádza to zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.3.2. Predchádza to jednému z najčastejších zlyhaní pri zaradení SaaS: nahratiu osobných údajov do nástroja pred dohodnutím podmienok sprostredkovateľa, povinností pri porušení ochrany osobných údajov a podmienok ďalších sprostredkovateľov.

Pre bezpečnosť aplikácií dodávateľa vyžaduje verzia Politika požiadaviek na bezpečnosť aplikácií pre MSP, aby obstarávanie:

špecifikovalo povinnosti pre zverejňovanie zraniteľností, časy reakcie a aplikáciu bezpečnostných záplat.

Pochádza to zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.3.2. Zároveň uvádza:

GM musí podľa potreby vyžiadať dokumentáciu alebo certifikácie (napr. SOC 2, ISO 27001, správy z bezpečnostného testovania) ako dôkaz súladu dodávateľa.

Pochádza to zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.3.2. Kľúčové slovo je dôkaz. Obstarávanie s bezpečnosťou ako podmienkou nákupu nestojí na vyhláseniach o dôvere. Stojí na preskúmateľných artefaktoch.

Obstarávacia brána Zenith Blueprint

Zenith Blueprint pristupuje k bezpečnosti dodávateľov ako k prevádzkovanej kontrole, nie ako k sloganu obstarávania. Vo fáze Controls in Action pokrýva Step 23 organizačné opatrenia 5.19 až 5.37 vrátane informačnej bezpečnosti vo vzťahoch s dodávateľmi.

Blueprint vysvetľuje:

Začína sa klasifikáciou dodávateľov. Nie všetci dodávatelia nesú rovnaké riziko. Upratovacia služba môže mať fyzický prístup do kancelárií, ale nie do sietí. Spoločnosť vykonávajúca penetračné testovanie alebo poskytovateľ cloudového hostingu však môže mať hlboký technický prístup priamo do jadra vašej infraštruktúry. Klasifikácia má zohľadniť, či dodávateľ priamo spracúva vaše informácie alebo s nimi nakladá, či poskytuje infraštruktúru alebo platformy, na ktorých prevádzkujete svoje činnosti, či vo vašom mene spravuje alebo udržiava systémy a či by jeho kompromitácia mohla ovplyvniť vaše ciele dôvernosti, integrity alebo dostupnosti.

Pri kontrole 5.20 je Blueprint priamy:

Medzi kľúčové oblasti typicky riešené v dodávateľských zmluvách patria povinnosti zachovávať dôvernosť; zodpovednosti za riadenie prístupu; technické a organizačné opatrenia na ochranu údajov, šifrovanie, bezpečný prenos, zálohovanie a záväzky dostupnosti; lehoty a protokoly nahlasovania incidentov; právo na audit vrátane frekvencie, rozsahu a prístupu k relevantným dôkazom; kontroly subdodávateľov; a ustanovenia pri ukončení zmluvy, ako je vrátenie alebo zničenie údajov, obnova aktív a deaktivácia účtov.

Záverom uvádza, že kontrola 5.20 je „vaša posledná páka vplyvu“ a „patrí do obstarávacej brány“. Po podpise zmluvy páka slabne. Pred podpisom možno dôkazy a povinnosti stanoviť ako podmienky nákupu.

Pri outsourcovanom vývoji pridáva fáza Controls in Action, Step 21, kontrola 8.30 ďalšiu požiadavku obstarávania. Blueprint uvádza:

Jadrom tejto kontroly je zásada, že bezpečnosť musí byť zmluvnou požiadavkou, nie ústnym očakávaním.

Outsourcované tímy musia spĺňať rovnaké štandardy bezpečného vývoja ako interné tímy vrátane statickej analýzy, vzájomného hodnotenia, šifrovania, MFA k repozitárom a viditeľnosti do kódu, architektonických rozhodnutí, zraniteľností, žiadostí o zmenu, CI/CD logov a výsledkov skenov.

Vybudujte RFP bránu s bezpečnosťou ako podmienkou nákupu za jedno popoludnie

Predpokladajme, že vaša organizácia chce platformu zákazníckej analytiky. Bude prijímať zákaznícke identifikátory, behaviorálne udalosti, metadáta podpory a referencie transakcií. Vlastník obchodnej oblasti chce rýchle schválenie. Bezpečnostný tím má jeden týždeň.

Začnite záznamom obstarávacej brány s použitím Politiky bezpečnosti tretích strán a dodávateľov, Politiky požiadaviek na bezpečnosť aplikácií, Politiky používania cloudových služieb, Politiky právneho a regulačného súladu a Step 23 dokumentu Zenith Blueprint ako zdrojových dokumentov.

K RFP priložte dotazník pre bezpečnosť ako podmienku nákupu. Vyhnite sa všeobecným otázkam typu „Šifrujete údaje?“ Klaďte otázky založené na dôkazoch:

1. Poskytnite aktuálnu nezávislú správu o bezpečnostnom uistení, certifikát alebo rovnocenné dôkazy o kontrolách.
2. Identifikujte miesta hostovania, možnosti lokalizácie údajov, umiestnenia záloh a miesta prístupu podpory.
3. Poskytnite DPA, zoznam ďalších sprostredkovateľov a proces oznámenia zmien ďalších sprostredkovateľov.
4. Potvrďte lehoty oznamovania incidentov vrátane podpory 24-hodinového včasného varovania tam, kde môžu byť spustené postupy NIS2, a podpory fázovaného hlásenia pre zákazníkov regulovaných DORA.
5. Poskytnite politiku zverejňovania zraniteľností, SLA pre nápravu podľa závažnosti a dôkazy o nedávnej správe a riadení nápravy zraniteľností.
6. Poskytnite dôkazy o produktovej bezpečnosti, napríklad opis životného cyklu bezpečného vývoja, súhrn penetračného testu, SBOM alebo vyhlásenie o transparentnosti komponentov a obdobie podpory bezpečnostných aktualizácií.
7. Potvrďte MFA, zásadu minimálnych oprávnení, logovanie, monitorovanie administrátorského prístupu a práva zákazníka na audit alebo vyžiadanie dôkazov.
8. Opíšte export, výmaz, vrátenie, podporu pri ukončení a pomoc pri prechode.
9. Uveďte významných subdodávateľov a závislosti IKT podporujúce službu.
10. Potvrďte, či sa údaje zákazníkov používajú na tréning, analytiku, zlepšovanie produktu alebo vývoj modelov AI, a identifikujte právny základ alebo model pokynov sprostredkovateľovi.

Potom dodávateľa ohodnoťte ešte pred rokovaním.

Nakoniec aktualizujte register rizík a vyhlásenie o uplatniteľnosti. Záznam o ošetrení rizík má ukázať, prečo sa uplatňujú kontroly ISO/IEC 27002:2022 5.19, 5.20 a 5.21, ktoré zmluvné a technické požiadavky boli vybrané, kto vlastní zostatkové riziko a aká periodicita monitorovania sa uplatňuje. Ak chce organizácia pokračovať napriek medzerám, použite formálny záznam akceptácie rizika s dátumom uplynutia platnosti, kompenzačnými kontrolami a schválením vrcholovým manažmentom.

Zmluvné ustanovenia, ktoré menia reguláciu na vymáhateľné povinnosti

Bezpečnostné očakávania sa musia zmeniť na zmluvné záväzky. Certifikát môže byť užitočný, ale zriedka odpovie na všetky otázky týkajúce sa vašej konkrétnej služby, umiestnenia údajov, subdodávateľov, modelu podpory, záväzkov pri incidentoch alebo práv pri ukončení.

Táto tabuľka je praktickým mostom medzi právnymi povinnosťami a prácou obstarávania. Pomáha aj právnemu oddeleniu, bezpečnosti a obstarávaniu vyjednávať z rovnakej kontrolnej základne.

Mapovanie medzi režimami súladu: jeden dodávateľský spis, mnoho povinností

Výhodou používania ISO/IEC 27001:2022 ako chrbtice je, že jeden spis dodávateľského uistenia môže podporiť viacero regulačných diskusií.

NIST CSF 2.0 je užitočný ako komunikačná vrstva. Jeho funkcia GOVERN zdôrazňuje právne, regulačné a zmluvné požiadavky, ochranu súkromia a povedomie o závislostiach. Výstupy GV.SC pre dodávateľský reťazec vyžadujú procesy riadenia rizík dodávateľského reťazca, roly dodávateľov, prioritizáciu dodávateľov podľa kritickosti, zmluvné požiadavky, due diligence, monitorovanie, plánovanie incidentov a plánovanie ukončenia.

To sa čisto mapuje na Step 23 dokumentu Zenith Blueprint a kontroly ISO/IEC 27002:2022 5.19 až 5.21 mapované v Zenith Controls. Predstavenstvu to zároveň dáva jazyk, ktorému rozumie: aktuálny stav, cieľový stav, medzera, riziko, opatrenie, vlastník a dátum.

Na čo sa budú pýtať audítori

Silný proces obstarávania s bezpečnosťou ako podmienkou nákupu má obstáť pod rôznymi auditnými pohľadmi.

Audítor ISO/IEC 27001:2022 začne kontextom a rozsahom ISMS. Bude sa pýtať, či sú zahrnuté rozhrania a závislosti dodávateľov, či požiadavky zainteresovaných strán zahŕňajú NIS2, DORA, GDPR a zákaznícke zmluvy a či sa dodávateľské riziká posudzujú konzistentne podľa metodiky rizík. Bude sledovať stopu do ošetrenia rizík, vyhlásenia o uplatniteľnosti, dodávateľských kontrol, prevádzkových dôkazov, interného auditu a preskúmania manažmentom.

Preskúmavateľ DORA sa zameria na obchodné funkcie podporované IKT, kritické alebo dôležité funkcie, záznamy závislostí od tretích strán, zmluvné ustanovenia, práva na audit a prístup, spoluprácu pri incidentoch, testovanie odolnosti, stratégie ukončenia a riziko koncentrácie. Ak SaaS podporuje kritickú alebo dôležitú funkciu, jednoduchý dodávateľský dotazník nebude stačiť.

Orgán NIS2 sa bude pýtať, ako organizácia posúdila kybernetickobezpečnostné praktiky dodávateľov, zraniteľnosti priamych dodávateľov, podporu oznamovania incidentov, závislosti kontinuity a rozhodnutia o bezpečnom obstarávaní. Otestuje, či dodávateľské uistenie podporuje vlastné povinnosti organizácie podľa Article 21 a Article 23.

Preskúmavateľ GDPR sa bude pýtať, či boli roly prevádzkovateľa a sprostredkovateľa pochopené pred začiatkom spracúvania, či bola DPA alebo rovnocenné podmienky dohodnuté pred zdieľaním údajov, či boli zverejnení ďalší sprostredkovatelia, či boli bezpečnostné opatrenia primerané, či je spolupráca pri porušení ochrany osobných údajov zmluvná a či je vrátenie alebo výmaz údajov vymáhateľný.

Audítor v štýle COBIT 2019 alebo ISACA sa zameria na správu a zodpovednosť: kto schválil dodávateľa, ktoré riziko bolo akceptované, či boli dodržané požiadavky politík, či sa sledujú výnimky a či boli vyvážené prínosy, riziká a zdroje.

Váš balík dôkazov má obsahovať klasifikáciu dodávateľa, schválenie vlastníkom obchodnej oblasti, posúdenie rizík, bezpečnostné požiadavky RFP, odpovede dodávateľa, DPA, bezpečnostnú prílohu, SLA, práva na audit, register ďalších sprostredkovateľov, záväzky k zraniteľnostiam, ustanovenia o incidentoch, dôkazy o umiestnení v cloude, dôkazy o logovaní a šifrovaní, podmienky ukončenia, záznamy o prehodnotení, výnimky a mapovanie vyhlásenia o uplatniteľnosti.

Bežné vzorce zlyhania pri nákupe softvéru

Prvým zlyhaním je zaobchádzanie s obstarávaním ako s komerčným pracovným postupom a s bezpečnosťou ako s technickým pracovným postupom. Kým bezpečnosť dostane zmluvu, organizácia sa už psychologicky zaviazala, dátum implementácie je oznámený a vyjednávacia páka je slabá.

Druhým zlyhaním je nahrádzanie dôkazov predpokladmi. Dodávateľ poskytne certifikát a kupujúci predpokladá, že odpovedá na každú otázku. Certifikácia môže pomôcť, ale nemusí pokrývať presný produkt, hostingový región, model podpory, reťazec subdodávateľov, povinnosti pri incidentoch, používanie údajov pre AI ani požiadavky na ukončenie.

Tretím zlyhaním je prehliadnutie nadväzujúceho rizika. Dodávateľ SaaS sa môže spoliehať na cloudový hosting, analytické nástroje, platformy podpory, offshore vývojové tímy, poskytovateľov modelov AI a spracovateľov platieb. Kontrola ISO/IEC 27002:2022 5.21 vyžaduje pozornosť dodávateľskému reťazcu IKT za priamym dodávateľom. Podľa DORA to súvisí so subdodávateľstvom a rizikom koncentrácie. Podľa GDPR to súvisí s ďalšími sprostredkovateľmi. Podľa NIS2 to súvisí so zraniteľnosťami priamych dodávateľov a kybernetickobezpečnostnými praktikami dodávateľov.

Štvrtým zlyhaním je slabý jazyk k incidentom. Zmluva, ktorá hovorí „dodávateľ bezodkladne oznámi zákazníkovi“, nemusí podporovať včasné varovanie podľa NIS2, fázované hlásenie podľa DORA, komunikáciu so zákazníkmi ani internú eskaláciu. Ustanovenia o incidentoch potrebujú lehoty, spúšťače, kontakty, povinnosti spolupráce a dôkazné povinnosti.

Piatym zlyhaním sú nejasné práva pri ukončení. Ak sa dodávateľ stane nebezpečným, nesúladným, bude nadobudnutý, insolventný alebo strategicky nevhodný, kupujúci potrebuje export, výmaz, podporu prechodu, deaktiváciu účtov a dôkaz o zničení. Ukončenie nie je právna dodatočná myšlienka. Je to kontrola odolnosti.

Od obstarávacej brány k živému dodávateľskému uisteniu

Obstarávanie s bezpečnosťou ako podmienkou nákupu sa nekončí podpisom. Zrelý dodávateľský životný cyklus v štýle Clarysec má päť etáp.

Pri dodávateľoch s vysokým rizikom má monitorovanie zahŕňať obnovu dôkazov, stretnutia k bezpečnostnému preskúmaniu, účasť na stolových cvičeniach incidentov, revíziu prístupových práv, výkazníctvo zraniteľností a bezpečnostných záplat, preskúmanie zmien služieb a aktualizácie ďalších sprostredkovateľov. Pri dodávateľoch s nižším rizikom môže postačovať ročné preskúmanie. Škálovateľnosť ISO 27001, proporcionalita NIS2 a proporcionalita DORA podporujú prispôsobenie, ale prispôsobenie musí byť odôvodnené a zdokumentované.

Ďalší krok s Clarysec

Ďalší rizikový nákup SaaS nebude čakať na dokonalý redizajn správy a riadenia. Začnite ďalšou požiadavkou na obstarávanie.

Použite Zenith Blueprint: An Auditor’s 30-Step Roadmap na implementáciu kontrol vzťahov s dodávateľmi v Step 23 a kontrol outsourcovaného vývoja v Step 21. Použite Zenith Controls na mapovanie kontrol ISO/IEC 27002:2022 5.19, 5.20 a 5.21 naprieč NIS2, DORA, GDPR, NIST CSF 2.0 a auditnými očakávaniami orientovanými na COBIT. Použite knižnicu politík Clarysec vrátane Politiky bezpečnosti tretích strán a dodávateľov, Politiky požiadaviek na bezpečnosť aplikácií, Politiky používania cloudových služieb a Politiky právneho a regulačného súladu, aby bola brána vymáhateľná.

Pred podpisom ďalšej zmluvy vyžadujte klasifikáciu dodávateľa, bezpečnostné dôkazy, pripravenosť DPA, záväzky pri incidentoch, riadenie zraniteľností, transparentnosť subdodávateľov, práva na audit a podmienky ukončenia.

To je obstarávanie s bezpečnosťou ako podmienkou nákupu. Takto CISO premieňajú regulačný tlak na nákupnú silu. Takto manažéri pre súlad menia prekrývajúce sa povinnosti na jeden dôkazový spis. Takto audítori vidia, že dodávateľské riziko bolo zvážené pred vznikom závislosti. A takto vlastníci obchodných oblastí nakupujú softvér rýchlejšie bez zdedenia neriadeného rizika.

Chcete zmeniť svoj ďalší nákup softvéru na kontrolu pripravenú na audit? Preskúmajte integrovaný balík politík Clarysec, stiahnite si Zenith Blueprint, preskúmajte Zenith Controls alebo si naplánujte demo a vybudujte program obstarávania s bezpečnosťou ako podmienkou nákupu, ktorý obstojí pred NIS2, DORA, GDPR, očakávaniami CRA a reálnym auditným preverovaním.