Pořizování softwaru podle principu secure-by-demand v roce 2026

Je úterní ráno na začátku roku 2026 a Maria, CISO rychle rostoucí evropské platební společnosti, prezentuje správní radě. Poslední bod programu by měl být rutinní: schválení nové platformy pro detekci podvodů využívající AI. Dodavatel má působivé demo, časově omezenou slevu, jednostránkový bezpečnostní přehled a standardní smlouvu.

Pak začnou otázky.

CEO se ptá: „Jak víme, že je tato platforma bezpečná? Naši klienti z finančních služeb požadují důkazy souladu s DORA a tento dodavatel se stane součástí naší kritické infrastruktury.“

Právní oddělení se ptá, zda je připravena smlouva o zpracování osobních údajů, kde budou zpracovávána zákaznická data z EU a zda jsou zveřejněni dílčí zpracovatelé. Vedoucí provozní odolnosti se ptá na plánování ukončení, exporty záloh a kontinuitu kritických funkcí. Inženýr produktové bezpečnosti požaduje oznamování zranitelností, důkazy o záplatování a SBOM nebo rovnocenné prohlášení o transparentnosti komponent. Oddělení nákupu pokládá otázku, která prodražuje dodavatelské riziko: „Můžeme to schválit teď a dokumenty si vyžádat až po podpisu?“

To je okamžik, kdy se moderní pořizování softwaru buď stává kontrolním opatřením, nebo budoucí zprávou o incidentu.

V roce 2026 se bezpečné pořizování softwaru nemůže spoléhat na dobrou vůli po uzavření smlouvy. Zabezpečení dodavatelského řetězce podle NIS2, riziko třetích stran v ICT podle DORA, odpovědnost zpracovatele podle GDPR a očekávání Cyber Resilience Act v oblasti produktové bezpečnosti posunuly zajištění dodavatelů do fáze nákupního rozhodnutí. Kupující potřebují pořizování softwaru podle principu secure-by-demand, při němž zákazník definuje bezpečnostní důkazy, smluvní doložky, schvalovací brány pro zapojení dodavatele a provozní odpovědnosti před nákupem.

Pro klienty Clarysec není odpovědí další tabulka, která zanikne v e-mailu. Odpovědí je systém kontrol pro pořizování v souladu s ISO/IEC 27001:2022, mapovaný prostřednictvím politik Clarysec, Zenith Blueprint: 30krokový plán auditora a Zenith Controls, aby každý nákup softwaru nebo SaaS měl obhajitelnou stopu od obchodní potřeby až po rozhodnutí o dodavatelském riziku.

Secure-by-demand je nové kontrolní opatření pro pořizování softwaru

Secure-by-design se obvykle řeší na straně dodavatele. Secure-by-demand je disciplína na straně kupujícího: organizace odmítá koupit software, pokud dodavatel nedokáže doložit, že bezpečnost, ochrana osobních údajů, odolnost, řešení zranitelností a auditovatelnost jsou zabudovány do nabídky.

Tím se mění nákupní rozhovor. Místo otázky „Máte bezpečnost?“ klade nákup přesnější otázky:

• Jaká data budete zpracovávat, kde a v jaké právní roli?
• Na které obchodní funkci budete závislí a jak je kritická?
• Jaké důkazy prokazují, že vaše opatření fungují, nikoli jen že jsou zdokumentována?
• K jakým lhůtám pro oznamování incidentů se zavážete?
• Jaké důkazy o oznamování zranitelností, záplatování, SBOM nebo VEX můžete poskytnout?
• Kteří subdodavatelé nebo dílčí zpracovatelé budou mít přístup k našim datům nebo službě?
• Můžeme během trvání smlouvy provést audit, inspekci nebo požádat o důkazy?
• Co se stane při ukončení, migraci, narušení bezpečnosti, insolvenci nebo dotazu regulačního orgánu?

ISO/IEC 27001:2022 poskytuje této změně páteř systému řízení. Kapitola 4 vyžaduje, aby organizace rozuměla kontextu, zainteresovaným stranám a rozsahu ISMS, včetně externích regulačních a dodavatelských požadavků. Kapitola 5 převádí dodavatelské riziko do odpovědnosti vedení a správy a řízení. Kapitola 6 vyžaduje posouzení rizik, ošetření rizik, výběr opatření, Prohlášení o aplikovatelnosti a rozhodnutí o zbytkovém riziku. Kapitola 8 vyžaduje řízené provozování procesů, včetně externě poskytovaných procesů. Kapitola 9 vyžaduje monitorování, interní audit a přezkoumání vedením.

To znamená, že pořizování softwaru není jen obchodní pracovní postup. Stává se provozovaným a auditovatelným procesem ISMS. Regulační orgány a auditoři se stále častěji ptají, proč organizace přijala dodavatele dříve, než porozuměla riziku. Pořizování podle principu secure-by-demand dává jasnou odpověď: riziko bylo posouzeno, ošetřeno, smluvně upraveno a přiřazeno dříve, než vznikla závislost.

Proč se NIS2, DORA, GDPR a CRA sbíhají při výběru dodavatele

Mariina správní rada klade správné otázky, protože jediný dodavatel softwaru může spustit několik povinností najednou.

NIS2 se uplatňuje podle odvětví, velikosti a kritičnosti; Annex I a Annex II zahrnují do působnosti mnoho digitálních, finančních, infrastrukturních, řízených služeb a organizací závislých na cloudu. Article 21 vyžaduje přiměřená a úměrná technická, provozní a organizační opatření, včetně zabezpečení dodavatelského řetězce, bezpečného pořizování, bezpečného vývoje a údržby, řešení zranitelností, řízení přístupu, správy aktiv, kontinuity, zvládání incidentů a posuzování účinnosti kontrol. Article 21(3) výslovně vyžaduje pozornost vůči zranitelnostem přímých dodavatelů a postupům kybernetické bezpečnosti dodavatelů. Article 23 zavádí odstupňované požadavky na hlášení významných incidentů, včetně včasného varování do 24 hodin a oznámení do 72 hodin.

DORA se od 17. ledna 2025 vztahuje na finanční subjekty v působnosti nařízení. Zavádí jednotné požadavky na řízení rizik v oblasti ICT, hlášení incidentů souvisejících s ICT, testování digitální provozní odolnosti a řízení rizik třetích stran v ICT. DORA je pro pořizování zvlášť preskriptivní. Finanční subjekty potřebují strategie pro rizika třetích stran v ICT, registry ujednání o ICT službách, náležitou péči, analýzu rizika koncentrace, písemné smlouvy s ustanoveními o bezpečnosti a odolnosti, práva na audit a přístup, povinnosti spolupráce, práva ukončení a plány ukončení. Articles 28 a 30 jsou ústřední pro rizika třetích stran v ICT a smluvní opatření, zatímco Articles 17 až 23 formují řízení incidentů a hlášení.

GDPR přidává bránu odpovědnosti zpracovatele. Articles 5, 28, 32, 33 a 34 vyžadují odpovědnost, smlouvy se zpracovateli, odpovídající zabezpečení, spolupráci při oznamování porušení zabezpečení a řešení dopadů na subjekty údajů. Dodavatel SaaS, který zpracovává osobní údaje, není jen dodavatel. Stává se součástí stavu souladu správce. DPA, technická a organizační opatření, seznam dílčích zpracovatelů, záruky pro předávání, pravidla uchovávání a povinnosti výmazu musí být pochopeny před zahájením zpracování.

Očekávání CRA přidávají zajištění produktu. I když kupující není výrobcem, nákupní týmy musí požadovat důkazy o bezpečném vývoji, řešení zranitelností, podpoře produktu, bezpečnostních aktualizacích, koordinovaném oznamování zranitelností a transparentnosti komponent, například SBOM nebo rovnocenné prohlášení. Tyto požadavky patří do RFP, bezpečnostních příloh a akceptačních bran.

Společný princip je jednoduchý: kupující organizace musí vědět, co kupuje, jaké riziko přebírá a jaké důkazy dokáže předložit, když se zeptají regulační orgány, zákazníci nebo auditoři.

Páteř opatření ISO 27001 pro zajištění dodavatelů

Nejúčinnější model pořizování podle principu secure-by-demand není budován po jednotlivých regulacích. Začíná opatřeními. Clarysec používá ISO/IEC 27001:2022 jako páteř ISMS, podporovanou pokyny k opatřením podle ISO/IEC 27002:2022 a mapováním napříč oblastmi souladu v Zenith Controls.

V Zenith Controls je zajištění dodavatelů ukotveno v opatřeních ISO/IEC 27002:2022 5.19, 5.20 a 5.21. Nejde o izolované položky kontrolního seznamu. Tvoří životní cyklus pořizování.

Zenith Controls mapuje tato opatření ISO na regulační a auditní očekávání. Nevytváří samostatná proprietární opatření nazvaná Zenith Controls. Pomáhá týmům porozumět tomu, jak opatření ISO/IEC 27002:2022 podporují NIS2, DORA, GDPR, NIST CSF 2.0 a zajištění orientované na COBIT.

Důležitá je i podpůrná síť opatření. Zajištění dodavatelů se propojuje se správou aktiv, řízením přístupu, cloudovou bezpečností, řízením zranitelností, protokolováním, řízením incidentů, připraveností ICT pro kontinuitu činností, bezpečným vývojem, zabezpečením aplikací, řízením konfigurace, zálohováním, redundancí, právním souladem, ochranou osobních údajů, řízením změn a nezávislým přezkumem. Pořizování proces koordinuje, ale vlastnictví rizika musí zahrnovat vlastníka obchodní oblasti, informační bezpečnost, právní oddělení, ochranu osobních údajů, IT, finance a vlastníka služby.

Brány politik Clarysec před podpisem

Model politik Clarysec záměrně posouvá zajištění dodavatelů proti proudu procesu. Nejsilnější formulace jsou tam, kde mají být: před podpisem smluv, před aktivací cloudových předplatných a před sdílením dat.

SME verze Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran společnosti Clarysec uvádí:

Posuďte a zdokumentujte rizika dodavatelů před podpisem smluv nebo udělením přístupu.

Toto pochází ze sekce „Cíle“, ustanovení politiky 3.3. Ustanovení je krátké, protože záměr opatření je nevyjednatelný: žádné posouzení rizik, žádná smlouva, žádný přístup.

Pro podniková prostředí Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran společnosti Clarysec posiluje předsmluvní bránu:

Všichni noví dodavatelé musí před uzavřením smlouvy projít zdokumentovaným bezpečnostním posouzením.

Toto pochází ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1. Stejná politika také identifikuje „práva na audit, inspekci a vyžádání bezpečnostních důkazů“ v sekci „Požadavky na správu a řízení“, ustanovení politiky 5.3.4.

Pro nákup cloudu a SaaS přidává SME Politika používání cloudových služeb praktickou schvalovací bránu:

Veškeré používání cloudových služeb musí před implementací nebo předplatným přezkoumat a schválit generální ředitel.

Toto pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.1. V malé organizaci může toto schválení odpovídat cloudovému řídicímu výboru. V podniku se z něj stává pracovní postup napříč nákupem, bezpečností, ochranou osobních údajů a architekturou. Podniková Politika používání cloudových služeb podporuje také smluvní požadavky na cloud, včetně vymahatelných ustanovení ve smlouvách s CSP.

Pro pořizování softwaru je podniková Politika požadavků na zabezpečení aplikací výslovná:

Pořizování softwaru nebo outsourcingová ujednání musí zahrnovat bezpečnostní požadavky v RFP, smlouvách a SLA, včetně ustanovení o lhůtách nápravy zranitelností a právech na audit třetích stran.

Toto pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4. Všimněte si pořadí: RFP, smlouvy a SLA. Bezpečnost se objevuje už ve fázi oslovení trhu, nikoli jako příloha po zadání zakázky.

Pro pořizování řízené GDPR vyžaduje SME Politika právního a regulačního souladu společnosti Clarysec:

Ustanovení smlouvy o zpracování osobních údajů (DPA) nebo rovnocenné smluvní podmínky musí být sjednány před sdílením jakýchkoli osobních nebo citlivých údajů.

Toto pochází ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.2. Tím se předchází jednomu z nejčastějších selhání při zapojení SaaS: nahrání osobních údajů do nástroje před sjednáním podmínek zpracovatele, povinností při porušení zabezpečení a podmínek pro dílčí zpracovatele.

Pro zabezpečení aplikací dodavatele vyžaduje SME Politika požadavků na zabezpečení aplikací, aby pořizování:

specifikovalo povinnosti pro oznamování zranitelností, reakční doby a záplatování.

Toto pochází ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.2. Dále uvádí:

Generální ředitel musí vyžádat dokumentaci nebo certifikace (např. SOC 2, ISO 27001, zprávy z bezpečnostních testů) jako důkaz souladu dodavatele, kde je to relevantní.

Toto pochází ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.3.2. Klíčovým slovem jsou důkazy. Pořizování podle principu secure-by-demand není založeno na prohlášeních o důvěře. Je založeno na přezkoumatelných artefaktech.

Nákupní brána Zenith Blueprint

Zenith Blueprint zachází s bezpečností dodavatelů jako s provozovaným opatřením, nikoli jako s nákupním sloganem. Ve fázi Controls in Action pokrývá Step 23 organizační opatření 5.19 až 5.37, včetně bezpečnosti informací ve vztazích s dodavateli.

Blueprint vysvětluje:

Začíná se klasifikací dodavatelů. Ne všichni dodavatelé představují stejné riziko. Úklidová služba může mít fyzický přístup do kanceláří, ale nikoli do sítí. Penetrační testovací společnost nebo poskytovatel cloudového hostingu může mít naopak hluboký technický přístup až do samotného jádra vaší infrastruktury. Klasifikace by měla zohlednit, zda dodavatel přímo nakládá s vašimi informacemi nebo je zpracovává, zda poskytuje infrastrukturu nebo platformy, na nichž provozujete své činnosti, zda spravuje nebo udržuje systémy vaším jménem a zda by jeho kompromitace mohla ovlivnit vaše cíle v oblasti důvěrnosti, integrity nebo dostupnosti.

Pro opatření 5.20 je Blueprint přímý:

Mezi klíčové oblasti obvykle řešené ve smlouvách s dodavateli patří povinnosti zachování důvěrnosti; odpovědnosti v oblasti řízení přístupu; technická a organizační opatření pro ochranu údajů, šifrování, bezpečný přenos, zálohování a závazky dostupnosti; lhůty a protokoly pro hlášení incidentů; právo na audit, včetně frekvence, rozsahu a přístupu k relevantním důkazům; kontroly subdodavatelů; a ustanovení pro konec smlouvy, například vrácení nebo zničení dat, obnova aktiv a deaktivace účtů.

Dochází k závěru, že opatření 5.20 je „vaší poslední pákou“ a „patří do nákupní brány“. Jakmile je smlouva podepsána, vyjednávací páka klesá. Před podpisem lze důkazy a povinnosti stanovit jako podmínky nákupu.

Pro outsourcovaný vývoj přidává fáze Controls in Action, Step 21, opatření 8.30, další nákupní požadavek. Blueprint uvádí:

Jádrem tohoto opatření je princip, že bezpečnost musí být smluvním požadavkem, nikoli ústním očekáváním.

Outsourcované týmy musí splňovat stejné standardy bezpečného vývoje jako interní týmy, včetně statické analýzy, kolegiálního přezkoumání, šifrování, MFA k repozitářům a viditelnosti do kódu, architektonických rozhodnutí, zranitelností, požadavků na změnu, CI/CD logů a výsledků skenování.

Vytvořte RFP bránu secure-by-demand za jedno odpoledne

Předpokládejme, že vaše organizace chce platformu pro zákaznickou analytiku. Bude přijímat zákaznické identifikátory, behaviorální události, metadata podpory a reference transakcí. Vlastník obchodní oblasti chce rychlé schválení. Bezpečnostní tým má jeden týden.

Začněte záznamem nákupní brány s využitím Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran, Politiky požadavků na zabezpečení aplikací, Politiky používání cloudových služeb, Politiky právního a regulačního souladu a Step 23 z Zenith Blueprint jako zdrojových dokumentů.

K RFP připojte dotazník secure-by-demand. Vyhněte se obecným otázkám typu „Šifrujete data?“ Pokládejte otázky řízené důkazy:

1. Poskytněte aktuální nezávislou zprávu o zajištění bezpečnosti, certifikát nebo rovnocenné důkazy o opatřeních.
2. Identifikujte umístění hostingu, možnosti umístění dat, umístění záloh a lokality podpůrného přístupu.
3. Poskytněte DPA, seznam dílčích zpracovatelů a proces oznámení změn dílčích zpracovatelů.
4. Potvrďte lhůty pro oznamování incidentů, včetně podpory včasného varování do 24 hodin tam, kde mohou být spuštěny pracovní postupy NIS2, a podpory fázovaného reportingu pro zákazníky regulované DORA.
5. Poskytněte politiku oznamování zranitelností, SLA pro záplatování podle závažnosti a důkazy o nedávném řízení nápravy zranitelností.
6. Poskytněte důkazy o produktové bezpečnosti, například popis životního cyklu bezpečného vývoje, shrnutí penetračního testu, SBOM nebo prohlášení o transparentnosti komponent a dobu podpory bezpečnostních aktualizací.
7. Potvrďte MFA, zásadu minimálních oprávnění, protokolování, monitorování administrátorského přístupu a práva zákazníka na audit nebo vyžádání důkazů.
8. Popište export, výmaz, vrácení, podporu ukončení a přechodovou podporu.
9. Uveďte významné subdodavatele a závislosti ICT podporující službu.
10. Potvrďte, zda jsou zákaznická data používána pro trénování, analytiku, zlepšování produktu nebo vývoj modelů AI, a identifikujte právní základ nebo model pokynů zpracovateli.

Poté dodavatele ohodnoťte ještě před vyjednáváním.

Nakonec aktualizujte registr rizik a Prohlášení o aplikovatelnosti. Záznam o ošetření rizik musí ukázat, proč se uplatní opatření ISO/IEC 27002:2022 5.19, 5.20 a 5.21, které smluvní a technické požadavky byly vybrány, kdo vlastní zbytkové riziko a jaká kadence monitorování se použije. Pokud chce obchodní oblast pokračovat navzdory mezerám, použijte formální záznam o přijetí rizika s datem expirace, kompenzačními opatřeními a schválením výkonného vedení.

Smluvní ustanovení, která převádějí regulaci na vymahatelné povinnosti

Bezpečnostní očekávání se musí stát smluvními závazky. Certifikát může být užitečný, ale zřídka odpoví na všechny otázky týkající se přesné služby, umístění dat, subdodavatelů, modelu podpory, závazků k incidentům nebo práv při ukončení.

Tato tabulka je praktickým mostem mezi právními povinnostmi a prací nákupu. Pomáhá také právnímu oddělení, bezpečnosti a nákupu vyjednávat ze stejného základního souboru bezpečnostních opatření.

Mapování napříč oblastmi souladu: jeden dodavatelský spis, mnoho povinností

Výhodou použití ISO/IEC 27001:2022 jako páteře je, že jeden spis zajištění dodavatele může podpořit více regulačních rozhovorů.

NIST CSF 2.0 je užitečný jako komunikační vrstva. Jeho funkce GOVERN zdůrazňuje povědomí o právních, regulačních, smluvních, soukromých a závislostních aspektech. Výstupy dodavatelského řetězce GV.SC vyžadují procesy řízení rizik dodavatelského řetězce, role dodavatelů, prioritizaci dodavatelů podle kritičnosti, smluvní požadavky, náležitou péči, monitorování, plánování incidentů a plánování ukončení.

To se čistě mapuje na Step 23 v Zenith Blueprint a opatření ISO/IEC 27002:2022 5.19 až 5.21, jak jsou mapována v Zenith Controls. Správním radám to zároveň poskytuje jazyk, kterému rozumějí: současný stav, cílový stav, mezera, riziko, opatření, vlastník a datum.

Na co se budou ptát auditoři

Silný proces pořizování podle principu secure-by-demand musí obstát pod různými auditními pohledy.

Auditor ISO/IEC 27001:2022 začne kontextem a rozsahem ISMS. Bude se ptát, zda jsou zahrnuta rozhraní a závislosti dodavatelů, zda požadavky zainteresovaných stran zahrnují NIS2, DORA, GDPR a zákaznické smlouvy a zda jsou dodavatelská rizika konzistentně posuzována podle metodiky řízení rizik. Bude sledovat stopu do ošetření rizik, Prohlášení o aplikovatelnosti, dodavatelských opatření, provozních důkazů, interního auditu a přezkoumání vedením.

Přezkoumávající osoba podle DORA se zaměří na obchodní funkce podporované ICT, kritické nebo významné funkce, záznamy závislostí na třetích stranách, smluvní doložky, práva na audit a přístup, spolupráci při incidentech, testování odolnosti, strategie ukončení a riziko koncentrace. Pokud SaaS podporuje kritickou nebo významnou funkci, odlehčený dodavatelský dotazník nebude stačit.

Orgán NIS2 se zeptá, jak organizace posuzovala postupy kybernetické bezpečnosti dodavatelů, zranitelnosti přímých dodavatelů, podporu oznamování incidentů, závislosti kontinuity a rozhodnutí o bezpečném pořizování. Ověří, zda zajištění dodavatelů podporuje vlastní povinnosti organizace podle Article 21 a Article 23.

Přezkoumávající osoba podle GDPR se zeptá, zda byly role správce a zpracovatele pochopeny před zahájením zpracování, zda byla DPA nebo rovnocenné podmínky sjednány před sdílením dat, zda byli zveřejněni dílčí zpracovatelé, zda byla bezpečnostní opatření odpovídající, zda je spolupráce při porušení zabezpečení smluvní a zda je vrácení nebo výmaz dat vymahatelný.

Auditor ve stylu COBIT 2019 nebo ISACA se zaměří na správu a odpovědnost: kdo dodavatele schválil, jaké riziko bylo přijato, zda byly dodrženy požadavky politik, zda jsou sledovány výjimky a zda byly vyváženy přínosy, rizika a zdroje.

Balíček důkazů musí obsahovat klasifikaci dodavatele, schválení vlastníkem obchodní oblasti, posouzení rizik, bezpečnostní požadavky RFP, odpovědi dodavatele, DPA, bezpečnostní přílohu, SLA, práva na audit, registr dílčích zpracovatelů, závazky ke zranitelnostem, incidentní doložky, důkazy o umístění v cloudu, důkazy o protokolování a šifrování, podmínky ukončení, záznamy o opětovném posouzení, výjimky a mapování Prohlášení o aplikovatelnosti.

Běžné vzorce selhání při nákupu softwaru

Prvním selháním je zacházet s pořizováním jako s obchodním pracovním postupem a s bezpečností jako s technickým pracovním postupem. V okamžiku, kdy bezpečnost obdrží smlouvu, obchodní oblast se již psychologicky zavázala, datum implementace bylo oznámeno a vyjednávací pozice je slabá.

Druhým selháním je nahrazení důkazů. Dodavatel poskytne certifikát a kupující předpokládá, že odpovídá na všechny otázky. Certifikace může pomoci, ale nemusí pokrývat přesný produkt, hostingový region, model podpory, řetězec subdodavatelů, incidentní povinnosti, použití dat pro AI nebo požadavky na ukončení.

Třetím selháním je opomenutí navazujícího rizika. Dodavatel SaaS může spoléhat na cloudový hosting, analytické nástroje, platformy podpory, offshore vývojové týmy, poskytovatele modelů AI a zpracovatele plateb. Opatření ISO/IEC 27002:2022 5.21 vyžaduje pozornost vůči dodavatelskému řetězci ICT za přímým dodavatelem. Pod DORA se to propojuje se subdodavateli a rizikem koncentrace. Pod GDPR se to propojuje s dílčími zpracovateli. Pod NIS2 se to propojuje se zranitelnostmi přímých dodavatelů a postupy kybernetické bezpečnosti dodavatelů.

Čtvrtým selháním je slabá incidentní formulace. Smlouva, která říká „dodavatel bezodkladně oznámí zákazníkovi“, nemusí podporovat včasné varování podle NIS2, fázované hlášení podle DORA, komunikaci se zákazníky nebo interní eskalaci. Incidentní doložky potřebují lhůty, spouštěče, kontakty, povinnosti spolupráce a důkazní povinnosti.

Pátým selháním jsou nejasná práva ukončení. Pokud se dodavatel stane nezabezpečeným, nesouladným, nabytým jiným subjektem, insolventním nebo strategicky nevhodným, kupující potřebuje export, výmaz, přechodovou podporu, deaktivaci účtů a důkazy o zničení. Ukončení není právní dodatek na závěr. Je to opatření odolnosti.

Od nákupní brány k živému zajištění dodavatelů

Pořizování podle principu secure-by-demand nekončí podpisem. Vyspělý dodavatelský životní cyklus ve stylu Clarysec má pět fází.

U vysoce rizikových dodavatelů musí monitorování zahrnovat obnovu důkazů, bezpečnostní přezkumné schůzky, účast na tabletop cvičeních incidentů, přezkum přístupových práv, reporting zranitelností a záplat, přezkum změn služby a aktualizace dílčích zpracovatelů. U méně rizikových dodavatelů může stačit každoroční přezkum. Škálovatelnost ISO 27001, proporcionalita NIS2 i proporcionalita DORA podporují přizpůsobení, ale přizpůsobení musí být odůvodněno a zdokumentováno.

Další krok s Clarysec

Další rizikový nákup SaaS nebude čekat na dokonalý redesign správy a řízení. Začněte příštím požadavkem na pořízení.

Použijte Zenith Blueprint: 30krokový plán auditora k implementaci Step 23 opatření pro vztahy s dodavateli a Step 21 opatření pro outsourcovaný vývoj. Použijte Zenith Controls k mapování opatření ISO/IEC 27002:2022 5.19, 5.20 a 5.21 napříč očekáváními auditu orientovanými na NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT. Použijte knihovnu politik Clarysec, včetně Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran, Politiky požadavků na zabezpečení aplikací, Politiky používání cloudových služeb a Politiky právního a regulačního souladu, aby byla brána vymahatelná.

Před podpisem další smlouvy vyžadujte klasifikaci dodavatele, bezpečnostní důkazy, připravenost DPA, závazky k incidentům, řešení zranitelností, transparentnost subdodavatelů, práva na audit a podmínky ukončení.

To je pořizování podle principu secure-by-demand. Tak CISO převádějí regulační tlak na nákupní sílu. Tak manažeři souladu mění překrývající se povinnosti v jeden spis důkazů. Tak auditoři vidí, že dodavatelské riziko bylo posouzeno dříve, než vznikla závislost. A tak vlastníci obchodních oblastí nakupují software rychleji, aniž by přebírali neřízené riziko.

Jste připraveni proměnit další nákup softwaru v kontrolní opatření připravené na audit? Prozkoumejte integrovanou sadu politik Clarysec, stáhněte si Zenith Blueprint, projděte Zenith Controls nebo si naplánujte demo a vybudujte program pořizování podle principu secure-by-demand, který obstojí vůči NIS2, DORA, GDPR, očekáváním CRA i skutečné auditorské kontrole.