Saugumo reikalavimais grindžiamas programinės įrangos pirkimas 2026 m.

Antradienio rytas 2026 m. pradžioje. Maria, sparčiai augančios Europos mokėjimų bendrovės vyriausioji informacijos saugumo pareigūnė (CISO), pristato klausimą valdybai. Paskutinis darbotvarkės punktas turėtų būti įprastas: naujos dirbtiniu intelektu pagrįstos sukčiavimo aptikimo platformos patvirtinimas. Tiekėjas turi įspūdingą demonstraciją, riboto galiojimo nuolaidą, vieno puslapio saugumo apžvalgą ir standartinę sutartį.

Tada prasideda klausimai.

Vyriausiasis vykdomasis pareigūnas klausia: „Kaip žinome, kad ši platforma yra saugi? Mūsų finansinių paslaugų klientai prašo DORA atitikties įrodymų, o šis tiekėjas tampa mūsų kritinės infrastruktūros dalimi.“

Teisės padalinys klausia, ar parengta duomenų tvarkymo sutartis, kur bus tvarkomi ES klientų duomenys ir ar atskleisti subtvarkytojai. Operacinio atsparumo vadovas klausia apie pasitraukimo planavimą, atsarginių kopijų eksportą ir kritinių funkcijų tęstinumą. Produkto saugumo inžinierius prašo pažeidžiamumų atskleidimo, pataisų diegimo įrodymų ir SBOM arba lygiaverčio komponentų skaidrumo pareiškimo. Pirkimų komanda užduoda klausimą, dėl kurio tiekėjų rizika tampa brangi: „Ar galime patvirtinti dabar, o dokumentus surinkti po pasirašymo?“

Būtent tuo momentu šiuolaikinis programinės įrangos pirkimas arba tampa kontrolės priemone, arba būsima incidento ataskaita.

2026 m. saugus programinės įrangos pirkimas nebegali remtis geranoriškumu po sutarties pasirašymo. NIS2 tiekimo grandinės saugumas, DORA IRT trečiųjų šalių rizika, GDPR duomenų tvarkytojo atskaitomybė ir Kibernetinio atsparumo akto produkto saugumo lūkesčiai perkėlė tiekėjų saugumo patikinimą į pirkimo sprendimo etapą. Pirkėjams reikia saugumo reikalavimais grindžiamo programinės įrangos pirkimo, kai klientas prieš pirkimą apibrėžia saugumo įrodymus, sutartines nuostatas, įtraukimo vartus ir operacines atsakomybes.

Clarysec klientams atsakymas nėra dar viena skaičiuoklė, pasimetanti el. pašte. Tai su ISO/IEC 27001:2022 suderinta pirkimo kontrolės priemonių sistema, susieta per Clarysec politikas, Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planą ir Zenith Controls, kad kiekvienas programinės įrangos ar SaaS pirkimas turėtų pagrįstą įrodymų seką nuo verslo poreikio iki sprendimo dėl tiekėjo rizikos.

Saugumo reikalavimais grindžiamas pirkimas yra nauja programinės įrangos pirkimo kontrolės priemonė

Saugumas pagal projektą paprastai aptariamas iš tiekėjo perspektyvos. Saugumo reikalavimais grindžiamas pirkimas yra pirkėjo taikoma disciplina: organizacija neperka programinės įrangos, jei tiekėjas negali įrodyti, kad saugumas, privatumas, atsparumas, pažeidžiamumų valdymas ir audituojamumas yra įtraukti į pasiūlymą.

Tai keičia pirkimo pokalbį. Užuot klaususi „Ar turite saugumą?“, pirkimų funkcija užduoda tikslesnius klausimus:

• Kokius duomenis tvarkysite, kur ir kokiu teisiniu vaidmeniu?
• Kuri verslo funkcija nuo jūsų priklausys ir koks jos kritiškumas?
• Kokie įrodymai patvirtina, kad jūsų kontrolės priemonės veikia, o ne tik yra dokumentuotos?
• Kokius incidentų pranešimo terminus įsipareigosite taikyti?
• Kokius pažeidžiamumų atskleidimo, pataisų diegimo, SBOM ar VEX įrodymus galite pateikti?
• Kurie subtiekėjai ar subtvarkytojai turės sąlytį su mūsų duomenimis ar paslauga?
• Ar sutarties galiojimo metu galėsime atlikti auditą, patikrą arba prašyti įrodymų?
• Kas vyksta sutarties nutraukimo, migracijos, pažeidimo, nemokumo ar reguliavimo institucijų užklausos atveju?

ISO/IEC 27001:2022 suteikia šiam pokyčiui valdymo sistemos pagrindą. 4 skyrius reikalauja, kad organizacija suprastų kontekstą, suinteresuotąsias šalis ir ISVS taikymo sritį, įskaitant išorinius reglamentavimo ir tiekėjų reikalavimus. 5 skyrius tiekėjų riziką paverčia vadovybės ir valdysenos atsakomybe. 6 skyrius reikalauja rizikos vertinimo, rizikos valdymo, kontrolės priemonių parinkimo, Taikomumo pareiškimo ir sprendimų dėl likutinės rizikos. 8 skyrius reikalauja kontroliuojamo procesų vykdymo, įskaitant išorės teikiamus procesus. 9 skyrius reikalauja stebėsenos, vidaus audito ir vadovybės peržiūros.

Tai reiškia, kad programinės įrangos pirkimas nėra tik komercinė darbo eiga. Jis tampa vykdomu ir audituojamu ISVS procesu. Reguliavimo institucijos ir auditoriai vis dažniau klausia, kodėl organizacija priėmė tiekėją dar nesupratusi rizikos. Saugumo reikalavimais grindžiamas pirkimas pateikia aiškų atsakymą: rizika buvo įvertinta, apdorota, įtvirtinta sutartyje ir priskirta atsakingam savininkui prieš sukuriant priklausomybę.

Kodėl NIS2, DORA, GDPR ir CRA susikerta tiekėjo atrankos etape

Marios valdyba užduoda teisingus klausimus, nes vienas programinės įrangos tiekėjas vienu metu gali sukelti kelis įpareigojimus.

NIS2 taikoma pagal sektorių, dydį ir kritiškumą; Annex I ir Annex II į taikymo sritį įtraukia daug skaitmeninių, finansinių, infrastruktūros, valdomų paslaugų ir nuo debesijos priklausomų organizacijų. Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant tiekimo grandinės saugumą, saugų įsigijimą, saugų kūrimą ir priežiūrą, pažeidžiamumų valdymą, prieigos kontrolę, turto valdymą, tęstinumą, incidentų valdymą ir kontrolės priemonių veiksmingumo vertinimą. Article 21(3) konkrečiai reikalauja atkreipti dėmesį į tiesioginių tiekėjų pažeidžiamumus ir tiekėjų kibernetinio saugumo praktiką. Article 23 nustato etapinius reikšmingų incidentų pranešimo lūkesčius, įskaitant ankstyvąjį įspėjimą per 24 valandas ir pranešimą per 72 valandas.

DORA nuo 2025 m. sausio 17 d. taikoma į taikymo sritį patenkantiems finansų subjektams. Ji nustato vienodus reikalavimus IRT rizikos valdymui, su IRT susijusių incidentų pranešimui, skaitmeninio operacinio atsparumo testavimui ir IRT trečiųjų šalių rizikos valdymui. DORA yra ypač detali pirkimų srityje. Finansų subjektams reikia IRT trečiųjų šalių rizikos strategijų, IRT paslaugų susitarimų registrų, išsamaus patikrinimo, koncentracijos rizikos analizės, rašytinių sutarčių su saugumo ir atsparumo nuostatomis, audito ir prieigos teisių, bendradarbiavimo pareigų, nutraukimo teisių ir pasitraukimo planų. Article 28 ir Article 30 yra pagrindiniai IRT trečiųjų šalių rizikai ir sutartinėms kontrolės priemonėms, o Article 17–23 formuoja incidentų valdymą ir pranešimą.

GDPR prideda duomenų tvarkytojo atskaitomybės vartus. Article 5, Article 28, Article 32, Article 33 ir Article 34 reikalauja atskaitomybės, duomenų tvarkytojo sutarčių, tinkamo saugumo, bendradarbiavimo pranešant apie pažeidimus ir poveikio duomenų subjektams valdymo. SaaS tiekėjas, kuris tvarko asmens duomenis, nėra tik tiekėjas. Jis tampa duomenų valdytojo atitikties laikysenos dalimi. DPA, techninės ir organizacinės priemonės, subtvarkytojų sąrašas, duomenų perdavimo apsaugos priemonės, saugojimo taisyklės ir ištrynimo įsipareigojimai turi būti suprasti prieš pradedant tvarkymą.

CRA lūkesčiai prideda produkto saugumo patikinimą. Net kai pirkėjas nėra gamintojas, pirkimų komandos turi reikalauti saugaus kūrimo, pažeidžiamumų valdymo, produkto palaikymo, saugumo atnaujinimų, koordinuoto pažeidžiamumų atskleidimo ir komponentų skaidrumo įrodymų, pavyzdžiui, SBOM arba lygiaverčio pareiškimo. Šie reikalavimai turi būti įtraukti į RFP, saugumo priedus ir priėmimo vartus.

Bendra tema paprasta: perkanti organizacija turi žinoti, ką perka, kokią riziką importuoja ir kokius įrodymus galės pateikti, kai jų paprašys reguliavimo institucijos, klientai ar auditoriai.

ISO 27001 kontrolės priemonių ašis tiekėjų saugumo patikinimui

Veiksmingiausias saugumo reikalavimais grindžiamo pirkimo modelis nėra reglamentas po reglamento. Jis pirmiausia grindžiamas kontrolės priemonėmis. Clarysec naudoja ISO/IEC 27001:2022 kaip ISVS ašį, paremtą ISO/IEC 27002:2022 kontrolės priemonių gairėmis ir kryžminės atitikties susiejimu Zenith Controls.

Zenith Controls tiekėjų saugumo patikinimas remiasi ISO/IEC 27002:2022 kontrolės priemonėmis 5.19, 5.20 ir 5.21. Tai nėra atskiri kontrolinio sąrašo punktai. Jie sudaro pirkimo gyvavimo ciklą.

Zenith Controls susieja šias ISO kontrolės priemones su reglamentavimo ir audito lūkesčiais. Tai nesukuria atskirų nuosavų kontrolės priemonių, vadinamų Zenith Controls. Tai padeda komandoms suprasti, kaip ISO/IEC 27002:2022 kontrolės priemonės palaiko NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT principais grindžiamą patikinimą.

Svarbus ir palaikantis kontrolės priemonių tinklas. Tiekėjų saugumo patikinimas siejasi su turto valdymu, prieigos kontrole, debesijos saugumu, pažeidžiamumų valdymu, žurnalavimu, incidentų valdymu, IRT pasirengimu veiklos tęstinumui, saugiu kūrimu, taikomųjų programų saugumu, konfigūracijų valdymu, atsarginėmis kopijomis, rezervavimu, teisine atitiktimi, privatumu, pakeitimų valdymu ir nepriklausoma peržiūra. Pirkimų funkcija koordinuoja procesą, tačiau rizikos atsakomybė turi apimti verslo savininką, informacijos saugumą, teisės padalinį, privatumo funkciją, IT, finansus ir paslaugos savininką.

Clarysec politikų vartai prieš pasirašymą

Clarysec politikų modelis sąmoningai perkelia tiekėjų saugumo patikinimą į ankstesnį etapą. Griežčiausia formuluotė pateikiama ten, kur ji turi būti: prieš pasirašant susitarimus, prieš aktyvuojant debesijos prenumeratas ir prieš dalijantis duomenimis.

Clarysec Trečiųjų šalių ir tiekėjų saugumo politikos MVĮ versijoje nurodoma:

Įvertinti ir dokumentuoti tiekėjų rizikas prieš pasirašant susitarimus arba suteikiant prieigą.

Tai pateikta skyriaus „Tikslai“ politikos 3.3 punkte. Punktas trumpas, nes kontrolės tikslas yra nederybinis: nėra rizikos vertinimo – nėra sutarties – nėra prieigos.

Įmonių aplinkoms Clarysec Trečiųjų šalių ir tiekėjų saugumo politika sustiprina ikisutartinius vartus:

Visi nauji tiekėjai prieš sutarties pasirašymą turi pereiti dokumentuotą saugumo vertinimą.

Tai pateikta skyriaus „Politikos įgyvendinimo reikalavimai“ politikos 6.1.1 punkte. Ta pati politika skyriaus „Valdysenos reikalavimai“ 5.3.4 punkte taip pat įvardija „Teises atlikti auditą, patikrą ir prašyti saugumo įrodymų“.

Debesijos ir SaaS pirkimui MVĮ Debesijos paslaugų naudojimo politika prideda praktinius patvirtinimo vartus:

Visi debesijos paslaugų naudojimo atvejai prieš įgyvendinimą arba prenumeratą turi būti peržiūrėti ir patvirtinti generalinio vadovo (GM).

Tai pateikta skyriaus „Valdysenos reikalavimai“ politikos 5.1 punkte. Mažoje organizacijoje toks patvirtinimas gali būti debesijos valdysenos tarybos atitikmuo. Įmonėje tai tampa darbo eiga tarp pirkimų, saugumo, privatumo ir architektūros funkcijų. Įmonių Debesijos paslaugų naudojimo politika taip pat palaiko sutartinius debesijos reikalavimus, įskaitant įgyvendinamas nuostatas CSP sutartyse.

Programinės įrangos įsigijimui įmonių Taikomųjų programų saugumo reikalavimų politika yra aiški:

Programinės įrangos įsigijimo arba išorės paslaugų susitarimuose turi būti įtraukti saugumo reikalavimai RFP, sutartyse ir SLA, įskaitant nuostatas dėl pažeidžiamumų šalinimo terminų ir trečiųjų šalių audito teisių.

Tai pateikta skyriaus „Valdysenos reikalavimai“ politikos 5.4 punkte. Atkreipkite dėmesį į eiliškumą: RFP, sutartys ir SLA. Saugumas atsiranda rinkos įtraukimo etape, o ne kaip priedas po laimėtojo pasirinkimo.

GDPR pagrįstam pirkimui Clarysec MVĮ Teisinės ir reglamentavimo atitikties politika reikalauja:

Duomenų tvarkymo sutarties (DPA) nuostatos arba lygiavertės sutartinės sąlygos turi būti suderintos prieš perduodant bet kokius asmens ar jautrius duomenis.

Tai pateikta skyriaus „Politikos įgyvendinimo reikalavimai“ politikos 6.3.2 punkte. Tai apsaugo nuo vienos dažniausių SaaS įtraukimo klaidų: asmens duomenų įkėlimo į įrankį prieš suderinant duomenų tvarkytojo sąlygas, pranešimo apie pažeidimus įsipareigojimus ir subtvarkytojų sąlygas.

Tiekėjo taikomųjų programų saugumui MVĮ Taikomųjų programų saugumo reikalavimų politika reikalauja, kad pirkimų funkcija:

nurodytų įsipareigojimus dėl pažeidžiamumų atskleidimo, reagavimo laikų ir pataisų diegimo.

Tai pateikta skyriaus „Valdysenos reikalavimai“ politikos 5.3.2 punkte. Joje taip pat nurodoma:

GM turi prašyti dokumentacijos arba sertifikatų (pvz., SOC 2, ISO 27001, saugumo testavimo ataskaitų) kaip tiekėjo atitikties įrodymų, kai taikytina.

Tai pateikta skyriaus „Politikos įgyvendinimo reikalavimai“ politikos 6.3.2 punkte. Pagrindinis žodis yra įrodymai. Saugumo reikalavimais grindžiamas pirkimas nesiremia pasitikėjimo teiginiais. Jis remiasi peržiūrimais artefaktais.

Zenith Blueprint pirkimo vartai

Zenith Blueprint tiekėjų saugumą traktuoja kaip vykdomą kontrolės priemonę, o ne pirkimų šūkį. Etape „Controls in Action“ 23 žingsnis apima Organizacines kontrolės priemones 5.19–5.37, įskaitant informacijos saugumą santykiuose su tiekėjais.

Blueprint paaiškina:

Pradedama nuo tiekėjų klasifikavimo. Ne visi tiekėjai kelia vienodą riziką. Valymo paslaugų teikėjas gali turėti fizinę prieigą prie biurų, bet ne prie tinklų. Įsiskverbimo testavimo įmonė arba prieglobos debesijoje paslaugų teikėjas, priešingai, gali turėti gilią techninę prieigą prie pačios jūsų infrastruktūros šerdies. Klasifikuojant reikėtų įvertinti, ar tiekėjas tiesiogiai tvarko jūsų informaciją, ar jis teikia infrastruktūrą arba platformas, kuriomis naudojatės, ar jis jūsų vardu valdo arba prižiūri sistemas ir ar jo kompromitavimas galėtų paveikti jūsų konfidencialumo, vientisumo arba prieinamumo tikslus.

Dėl kontrolės priemonės 5.20 Blueprint formuluoja tiesiogiai:

Pagrindinės sritys, kurios paprastai aptariamos susitarimuose su tiekėjais, apima konfidencialumo įsipareigojimus; prieigos kontrolės atsakomybes; technines ir organizacines priemones duomenų apsaugai, šifravimui, saugiam perdavimui, atsarginėms kopijoms ir prieinamumo įsipareigojimams; incidentų pranešimo terminus ir protokolus; teisę atlikti auditą, įskaitant dažnumą, taikymo sritį ir prieigą prie susijusių įrodymų; subtiekėjų kontrolės priemones; ir sutarties pabaigos nuostatas, tokias kaip duomenų grąžinimas ar sunaikinimas, turto atkūrimas ir paskyrų deaktyvavimas.

Jame daroma išvada, kad kontrolės priemonė 5.20 yra „paskutinė jūsų sverto linija“ ir „priklauso pirkimo vartams“. Pasirašius sutartį, derybinis svertas sumažėja. Prieš pasirašymą įrodymai ir įsipareigojimai gali būti pirkimo sąlygos.

Išoriniam kūrimui etapo „Controls in Action“ 21 žingsnis, kontrolės priemonė 8.30, prideda dar vieną pirkimo reikalavimą. Blueprint nurodo:

Šios kontrolės priemonės esmė yra principas, kad saugumas turi būti sutartinis reikalavimas, o ne žodinis lūkestis.

Išorinės komandos turi atitikti tuos pačius saugaus kūrimo standartus kaip vidinės komandos, įskaitant statinę analizę, tarpusavio peržiūrą, šifravimą, MFA prieigai prie saugyklų ir matomumą į kodą, architektūros sprendimus, pažeidžiamumus, pakeitimų prašymus, CI/CD žurnalus ir skenavimo rezultatus.

Sukurkite saugumo reikalavimais grindžiamus RFP vartus per vieną popietę

Tarkime, jūsų organizacijai reikia klientų analitikos platformos. Ji rinks klientų identifikatorius, elgsenos įvykius, palaikymo metaduomenis ir operacijų nuorodas. Verslo savininkas nori greito patvirtinimo. Saugumo komanda turi vieną savaitę.

Pradėkite nuo pirkimo vartų įrašo, naudodami Trečiųjų šalių ir tiekėjų saugumo politiką, Taikomųjų programų saugumo reikalavimų politiką, Debesijos paslaugų naudojimo politiką, Teisinės ir reglamentavimo atitikties politiką ir Zenith Blueprint 23 žingsnį kaip šaltinio dokumentus.

Pridėkite prie RFP saugumo reikalavimais grindžiamą klausimyną. Venkite bendrų klausimų, tokių kaip „Ar šifruojate duomenis?“ Užduokite įrodymais grindžiamus klausimus:

1. Pateikite galiojančią nepriklausomą saugumo patikinimo ataskaitą, sertifikatą arba lygiaverčius kontrolės priemonių įrodymus.
2. Nurodykite prieglobos vietas, duomenų buvimo vietos pasirinkimus, atsarginių kopijų vietas ir palaikymo prieigos vietas.
3. Pateikite DPA, subtvarkytojų sąrašą ir pranešimo apie subtvarkytojų pakeitimus procesą.
4. Patvirtinkite incidentų pranešimo terminus, įskaitant 24 valandų ankstyvojo įspėjimo palaikymą, kai gali būti inicijuotos NIS2 procedūros, ir etapinio pranešimo palaikymą DORA reguliuojamiems klientams.
5. Pateikite pažeidžiamumų atskleidimo politiką, pataisų diegimo SLA pagal sunkumą ir naujausius pažeidžiamumų šalinimo valdysenos įrodymus.
6. Pateikite produkto saugumo įrodymus, pavyzdžiui, saugaus kūrimo gyvavimo ciklo aprašą, įsiskverbimo testavimo santrauką, SBOM arba komponentų skaidrumo pareiškimą ir saugumo atnaujinimų palaikymo laikotarpį.
7. Patvirtinkite MFA, mažiausių privilegijų principą, žurnalavimą, administratoriaus lygmens prieigos stebėseną ir kliento audito arba įrodymų prašymo teises.
8. Aprašykite eksportą, ištrynimą, grąžinimą, nutraukimo palaikymą ir perėjimo pagalbą.
9. Išvardykite reikšmingus subtiekėjus ir IRT priklausomybes, palaikančias paslaugą.
10. Patvirtinkite, ar klientų duomenys naudojami mokymui, analitikai, produkto tobulinimui arba DI modelių kūrimui, ir nurodykite teisinį pagrindą arba duomenų tvarkytojui teikiamų nurodymų modelį.

Tada įvertinkite tiekėją prieš derybas.

Galiausiai atnaujinkite rizikų registrą ir Taikomumo pareiškimą. Rizikos valdymo įrašas turėtų parodyti, kodėl taikomos ISO/IEC 27002:2022 kontrolės priemonės 5.19, 5.20 ir 5.21, kokie sutartiniai ir techniniai reikalavimai buvo parinkti, kas yra likutinės rizikos savininkas ir koks stebėsenos periodiškumas taikomas. Jei verslas nori tęsti nepaisant spragų, naudokite formalų rizikos priėmimo įrašą su galiojimo pabaigos data, kompensuojančiomis kontrolės priemonėmis ir vadovybės patvirtinimu.

Sutartinės nuostatos, kurios reglamentavimą paverčia įgyvendinamais įsipareigojimais

Saugumo lūkesčiai turi tapti sutartiniais įsipareigojimais. Sertifikatas gali būti naudingas, tačiau jis retai atsako į visus klausimus apie jūsų konkrečią paslaugą, duomenų vietą, subtiekėjus, palaikymo modelį, incidentų įsipareigojimus ar pasitraukimo teises.

Ši lentelė yra praktinis tiltas tarp teisinių įpareigojimų ir pirkimų darbo. Ji taip pat padeda teisės, saugumo ir pirkimų funkcijoms derėtis remiantis ta pačia kontrolės priemonių baze.

Kryžminės atitikties susiejimas: viena tiekėjo byla, daug įpareigojimų

ISO/IEC 27001:2022 naudojimo kaip pagrindo privalumas yra tai, kad viena tiekėjo saugumo patikinimo byla gali palaikyti kelis reglamentavimo pokalbius.

NIST CSF 2.0 yra naudingas kaip komunikacijos sluoksnis. Jo GOVERN funkcija akcentuoja teisinį, reglamentavimo, sutartinį, privatumo ir priklausomybių supratimą. GV.SC tiekimo grandinės rezultatai reikalauja tiekimo grandinės rizikos valdymo procesų, tiekėjų vaidmenų, tiekėjų prioritetizavimo pagal kritiškumą, sutartinių reikalavimų, išsamaus patikrinimo, stebėsenos, incidentų planavimo ir nutraukimo planavimo.

Tai aiškiai susiejama su Zenith Blueprint 23 žingsniu ir ISO/IEC 27002:2022 kontrolės priemonėmis 5.19–5.21, kaip jos susietos Zenith Controls. Tai taip pat suteikia valdyboms suprantamą kalbą: esama būsena, tikslinė būsena, spraga, rizika, veiksmas, savininkas ir data.

Ko klaus auditoriai

Stiprus saugumo reikalavimais grindžiamo pirkimo procesas turi atlaikyti skirtingas audito perspektyvas.

ISO/IEC 27001:2022 auditorius pradės nuo ISVS konteksto ir taikymo srities. Jis klaus, ar tiekėjų sąsajos ir priklausomybės yra įtrauktos, ar suinteresuotųjų šalių reikalavimai apima NIS2, DORA, GDPR ir klientų sutartis, ir ar tiekėjų rizikos nuosekliai vertinamos pagal rizikos metodiką. Auditorius seks pėdsaką į rizikos valdymą, Taikomumo pareiškimą, tiekėjų kontrolės priemones, operacinius įrodymus, vidaus auditą ir vadovybės peržiūrą.

DORA peržiūrą atliekantis asmuo sutelks dėmesį į IRT palaikomas verslo funkcijas, kritines ar svarbias funkcijas, trečiųjų šalių priklausomybių įrašus, sutartines nuostatas, audito ir prieigos teises, bendradarbiavimą incidentų atvejais, atsparumo testavimą, pasitraukimo strategijas ir koncentracijos riziką. Jei SaaS palaiko kritinę ar svarbią funkciją, lengvas tiekėjo klausimynas nebus pakankamas.

NIS2 institucija klaus, kaip organizacija įvertino tiekėjų kibernetinio saugumo praktiką, tiesioginių tiekėjų pažeidžiamumus, incidentų pranešimo palaikymą, tęstinumo priklausomybes ir saugaus įsigijimo sprendimus. Ji tikrins, ar tiekėjų saugumo patikinimas palaiko pačios organizacijos Article 21 ir Article 23 įpareigojimus.

GDPR peržiūrą atliekantis asmuo klaus, ar duomenų valdytojo ir duomenų tvarkytojo vaidmenys buvo suprasti prieš pradedant tvarkymą, ar DPA arba lygiavertės sąlygos buvo suderintos prieš dalijantis duomenimis, ar subtvarkytojai buvo atskleisti, ar saugumo priemonės buvo tinkamos, ar bendradarbiavimas pažeidimų atvejais yra sutartinis ir ar duomenų grąžinimas arba ištrynimas yra įgyvendinamas.

COBIT 2019 arba ISACA tipo auditorius sutelks dėmesį į valdyseną ir atskaitomybę: kas patvirtino tiekėją, kokia rizika buvo priimta, ar buvo laikomasi politikos reikalavimų, ar stebimos išimtys ir ar buvo subalansuota nauda, rizika ir ištekliai.

Jūsų įrodymų paketas turėtų apimti tiekėjo klasifikavimą, verslo savininko patvirtinimą, rizikos vertinimą, RFP saugumo reikalavimus, tiekėjo atsakymus, DPA, saugumo priedą, SLA, audito teises, subtvarkytojų registrą, pažeidžiamumų įsipareigojimus, incidentų nuostatas, debesijos vietos įrodymus, žurnalavimo ir šifravimo įrodymus, pasitraukimo sąlygas, pakartotinio vertinimo įrašus, išimtis ir Taikomumo pareiškimo susiejimą.

Dažniausi programinės įrangos pirkimo nesėkmių modeliai

Pirmoji nesėkmė – pirkimų traktavimas kaip komercinės darbo eigos, o saugumo – kaip techninės darbo eigos. Kol saugumo komanda gauna sutartį, verslas jau psichologiškai įsipareigojęs, įgyvendinimo data paskelbta, o derybinis svertas silpnas.

Antroji nesėkmė – įrodymų pakeitimas prielaidomis. Tiekėjas pateikia sertifikatą, o pirkėjas daro prielaidą, kad jis atsako į visus klausimus. Sertifikavimas gali padėti, tačiau jis gali neapimti konkretaus produkto, prieglobos regiono, palaikymo modelio, subtiekėjų grandinės, incidentų įsipareigojimų, DI duomenų naudojimo ar pasitraukimo reikalavimų.

Trečioji nesėkmė – nepastebėta tolesnės grandies rizika. SaaS tiekėjas gali remtis priegloba debesijoje, analitikos įrankiais, palaikymo platformomis, užsienyje veikiančiomis kūrimo komandomis, DI modelių teikėjais ir mokėjimų tvarkytojais. ISO/IEC 27002:2022 kontrolės priemonė 5.21 reikalauja atkreipti dėmesį į IRT tiekimo grandinę už tiesioginio tiekėjo. Pagal DORA tai siejasi su subtiekimu ir koncentracijos rizika. Pagal GDPR – su subtvarkytojais. Pagal NIS2 – su tiesioginių tiekėjų pažeidžiamumais ir tiekėjų kibernetinio saugumo praktika.

Ketvirtoji nesėkmė – silpna incidentų kalba. Sutartis, kurioje nurodyta, kad „tiekėjas nedelsdamas praneš klientui“, gali nepalaikyti NIS2 ankstyvojo įspėjimo, DORA etapinio pranešimo, klientų komunikacijos ar vidinio eskalavimo. Incidentų nuostatoms reikia terminų, aktyvavimo sąlygų, kontaktų, bendradarbiavimo pareigų ir įrodymų įsipareigojimų.

Penktoji nesėkmė – neaiškios pasitraukimo teisės. Jei tiekėjas tampa nesaugus, neatitinkantis reikalavimų, įsigyjamas, nemokus arba strategiškai netinkamas, pirkėjui reikia eksporto, ištrynimo, perėjimo palaikymo, paskyrų deaktyvavimo ir sunaikinimo įrodymų. Pasitraukimas nėra teisinė mintis po fakto. Tai atsparumo kontrolės priemonė.

Nuo pirkimo vartų iki veikiančio tiekėjų saugumo patikinimo

Saugumo reikalavimais grindžiamas pirkimas nesibaigia pasirašymu. Brandus Clarysec tipo tiekėjo gyvavimo ciklas turi penkis etapus.

Didelės rizikos tiekėjams stebėsena turėtų apimti įrodymų atnaujinimą, saugumo peržiūros susitikimus, dalyvavimą incidentų stalo pratybose, prieigos peržiūrą, pažeidžiamumų ir pataisų ataskaitų teikimą, paslaugos pakeitimų peržiūrą ir subtvarkytojų atnaujinimus. Mažesnės rizikos tiekėjams gali pakakti metinės peržiūros. ISO 27001 mastelio pritaikymas, NIS2 proporcingumas ir DORA proporcingumas palaiko pritaikymą, tačiau pritaikymas turi būti pagrįstas ir dokumentuotas.

Kitas Clarysec žingsnis

Kitas rizikingas SaaS pirkimas nelauks tobulo valdysenos pertvarkymo. Pradėkite nuo kito pirkimo prašymo.

Naudokite Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planą, kad įgyvendintumėte 23 žingsnio tiekėjų santykių kontrolės priemones ir 21 žingsnio išorinio kūrimo kontrolės priemones. Naudokite Zenith Controls, kad susietumėte ISO/IEC 27002:2022 kontrolės priemones 5.19, 5.20 ir 5.21 su NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT orientuotais audito lūkesčiais. Naudokite Clarysec politikų biblioteką, įskaitant Trečiųjų šalių ir tiekėjų saugumo politiką, Taikomųjų programų saugumo reikalavimų politiką, Debesijos paslaugų naudojimo politiką ir Teisinės ir reglamentavimo atitikties politiką, kad vartai būtų įgyvendinami.

Prieš pasirašant kitą sutartį, pareikalaukite tiekėjo klasifikavimo, saugumo įrodymų, DPA pasirengimo, incidentų įsipareigojimų, pažeidžiamumų valdymo, subtiekėjų skaidrumo, audito teisių ir pasitraukimo sąlygų.

Tai ir yra saugumo reikalavimais grindžiamas pirkimas. Taip CISO reguliacinį spaudimą paverčia pirkimo galia. Taip atitikties vadovai persidengiančius įpareigojimus paverčia viena įrodymų byla. Taip auditoriai mato, kad tiekėjo rizika buvo įvertinta prieš sukuriant priklausomybę. Ir taip verslo savininkai greičiau perka programinę įrangą nepaveldėdami nevaldomos rizikos.

Pasirengę kitą programinės įrangos pirkimą paversti auditui tinkama kontrolės priemone? Susipažinkite su integruotu Clarysec politikų rinkiniu, atsisiųskite Zenith Blueprint, peržiūrėkite Zenith Controls arba suplanuokite demonstraciją, kad sukurtumėte saugumo reikalavimais grindžiamą pirkimo programą, kuri atlaikytų NIS2, DORA, GDPR, CRA lūkesčius ir realų auditoriaus tikrinimą.