Drošības prasībās balstīts programmatūras iepirkums 2026. gadā

Ir 2026. gada sākuma otrdienas rīts, un Marija, strauji augoša Eiropas maksājumu uzņēmuma informācijas drošības vadītāja (CISO), sniedz prezentāciju valdei. Pēdējam darba kārtības punktam vajadzētu būt rutīnas jautājumam: apstiprināt jaunu ar AI darbinātu krāpšanas atklāšanas platformu. Piegādātājam ir iespaidīga demonstrācija, ierobežota laika atlaide, vienas lapas drošības pārskats un standarta līgums.

Tad sākas jautājumi.

Galvenais izpilddirektors jautā: “Kā mēs zinām, ka šī platforma ir droša? Mūsu finanšu pakalpojumu klienti prasa DORA atbilstības pierādījumus, un šis piegādātājs kļūst par daļu no mūsu kritiskās infrastruktūras.”

Juridiskais dienests jautā, vai Datu apstrādes līgums ir gatavs, kur tiks apstrādāti ES klientu dati un vai apakšapstrādātāji ir atklāti. Par darbības noturību atbildīgā persona jautā par izstāšanās plānošanu, rezerves kopiju eksportu un kritisko funkciju nepārtrauktību. Produkta drošības inženieris prasa ievainojamību izpaušanas procesu, ielāpu pārvaldības pierādījumus un SBOM vai līdzvērtīgu komponentu pārredzamības paziņojumu. Iepirkumu komanda uzdod jautājumu, kas piegādātāju risku padara dārgu: “Vai varam apstiprināt tagad un dokumentus savākt pēc parakstīšanas?”

Tas ir brīdis, kad mūsdienīgs programmatūras iepirkums vai nu kļūst par kontroles pasākumu, vai par nākotnes incidenta ziņojumu.

2026. gadā drošs programmatūras iepirkums vairs nevar balstīties uz piegādātāja labas gribas apliecinājumiem pēc līguma noslēgšanas. NIS2 piegādes ķēdes drošība, DORA IKT trešo pušu risks, GDPR apstrādātāja pārskatatbildība un Cyber Resilience Act produkta drošības prasības ir pārcēlušas piegādātāju drošības apliecinājumu uz iepirkuma lēmuma posmu. Pircējiem ir vajadzīgs drošības prasībās balstīts programmatūras iepirkums, kurā klients pirms pirkuma nosaka drošības pierādījumus, līguma klauzulas, ieviešanas kontrolpunktus un operacionālās atbildības.

Clarysec klientiem atbilde nav vēl viena izklājlapa, kas pazūd e-pastā. Tā ir ar ISO/IEC 27001:2022 saskaņota iepirkuma kontroles sistēma, kas kartēta, izmantojot Clarysec politikas, Zenith Blueprint: An Auditor’s 30-Step Roadmap un Zenith Controls, lai katram programmatūras vai SaaS pirkumam būtu pamatota audita pēda no biznesa vajadzības līdz piegādātāja riska lēmumam.

Drošības prasībās balstīta pieeja ir jaunais programmatūras iepirkuma kontroles pasākums

Drošība pēc projektēšanas parasti tiek apspriesta no piegādātāja puses. Drošības prasībās balstīta pieeja ir pircēja puses disciplīna: organizācija atsakās iegādāties programmatūru, ja piegādātājs nevar pierādīt, ka drošība, privātums, noturība, ievainojamību pārvaldība un auditējamība ir iekļautas piedāvājumā.

Tas maina iepirkuma sarunu. Tā vietā, lai jautātu: “Vai jums ir drošība?”, iepirkums uzdod precīzākus jautājumus:

• Kādus datus jūs apstrādāsiet, kur un kādā juridiskā lomā?
• Kura biznesa funkcija būs atkarīga no jums, un cik kritiska tā ir?
• Kādi pierādījumi apliecina, ka jūsu kontroles pasākumi darbojas, nevis tikai ir dokumentēti?
• Kādus incidentu paziņošanas termiņus jūs apņematies ievērot?
• Kādus ievainojamību izpaušanas, ielāpu pārvaldības, SBOM vai VEX pierādījumus jūs varat sniegt?
• Kuri apakšuzņēmēji vai apakšapstrādātāji piekļūs mūsu datiem vai pakalpojumam?
• Vai līguma darbības laikā mēs varam auditēt, pārbaudīt vai pieprasīt pierādījumus?
• Kas notiek līguma izbeigšanas, migrācijas, pārkāpuma, maksātnespējas vai regulatora pieprasījuma gadījumā?

ISO/IEC 27001:2022 nodrošina pārvaldības sistēmas pamatu šai pārejai. 4. punkts prasa organizācijai izprast kontekstu, ieinteresētās puses un IDPS darbības jomu, tostarp ārējās regulatīvās un piegādātāju prasības. 5. punkts pārvērš piegādātāju risku par vadības un pārvaldības atbildību. 6. punkts prasa risku izvērtēšanu, riska apstrādi, kontroles pasākumu atlasi, piemērojamības deklarāciju un atlikušā riska lēmumus. 8. punkts prasa procesu kontrolētu darbību, tostarp ārēji nodrošinātus procesus. 9. punkts prasa uzraudzību, iekšējo auditu un vadības pārskatīšanu.

Tas nozīmē, ka programmatūras iepirkums nav tikai komerciāla darbplūsma. Tas kļūst par operacionalizētu un auditējamu IDPS procesu. Regulatori un auditori arvien biežāk jautā, kāpēc organizācija pieņēma piegādātāju, pirms tā izprata risku. Drošības prasībās balstīts iepirkums sniedz skaidru atbildi: risks tika izvērtēts, apstrādāts, ietverts līgumā un piešķirts pirms atkarības izveides.

Kāpēc NIS2, DORA, GDPR un CRA satiekas piegādātāja atlases posmā

Marijas valde uzdod pareizos jautājumus, jo viens programmatūras piegādātājs vienlaikus var izraisīt vairākus pienākumus.

NIS2 piemērošana ir atkarīga no nozares, lieluma un kritiskuma, un I pielikums un II pielikums darbības jomā iekļauj daudzas digitālās, finanšu, infrastruktūras, pārvaldīto pakalpojumu un no mākoņpakalpojumiem atkarīgas organizācijas. Article 21 prasa atbilstošus un samērīgus tehniskus, operatīvus un organizatoriskus pasākumus, tostarp piegādes ķēdes drošību, drošu iegādi, drošu izstrādi un uzturēšanu, ievainojamību pārvaldību, piekļuves kontroli, aktīvu pārvaldību, nepārtrauktību, incidentu apstrādi un kontroles efektivitātes izvērtēšanu. Article 21(3) īpaši prasa pievērst uzmanību tiešo piegādātāju ievainojamībām un piegādātāju kiberdrošības praksēm. Article 23 nosaka pakāpeniskas nozīmīgu incidentu ziņošanas prasības, tostarp agrīno brīdinājumu 24 stundu laikā un paziņošanu 72 stundu laikā.

DORA no 2025. gada 17. janvāra attiecas uz darbības jomā esošām finanšu iestādēm. Tā nosaka vienotas prasības IKT risku pārvaldībai, ar IKT saistītu incidentu ziņošanai, digitālās darbības noturības testēšanai un IKT trešo pušu risku pārvaldībai. DORA iepirkuma jautājumos ir īpaši preskriptīva. Finanšu iestādēm ir nepieciešamas IKT trešo pušu riska stratēģijas, IKT pakalpojumu vienošanos reģistri, sākotnējā izpēte, koncentrācijas riska analīze, rakstiski līgumi ar drošības un noturības noteikumiem, audita un piekļuves tiesības, sadarbības pienākumi, izbeigšanas tiesības un izstāšanās plāni. Articles 28 un 30 ir centrāli IKT trešo pušu riskam un līgumiskajiem kontroles pasākumiem, savukārt Articles 17 to 23 nosaka incidentu pārvaldības un ziņošanas ietvaru.

GDPR pievieno apstrādātāja pārskatatbildības kontrolpunktu. Articles 5, 28, 32, 33 un 34 prasa pārskatatbildību, apstrādātāja līgumus, atbilstošu drošību, sadarbību paziņošanā par pārkāpumu un datu subjektu ietekmes pārvaldību. SaaS piegādātājs, kas apstrādā personas datus, nav tikai piegādātājs. Tas kļūst par daļu no pārziņa atbilstības stāvokļa. DPA, tehniskie un organizatoriskie pasākumi, apakšapstrādātāju saraksts, datu nosūtīšanas aizsardzības pasākumi, glabāšanas noteikumi un dzēšanas pienākumi ir jāizprot pirms apstrādes sākuma.

CRA prasības pievieno produkta drošības apliecinājumu. Pat ja pircējs nav ražotājs, iepirkuma komandām jāpieprasa drošas izstrādes, ievainojamību pārvaldības, produkta atbalsta, drošības atjauninājumu, koordinētas ievainojamību izpaušanas un komponentu pārredzamības pierādījumi, piemēram, SBOM vai līdzvērtīgs paziņojums. Šīm prasībām jābūt RFP, drošības pielikumos un pieņemšanas kontrolpunktos.

Kopējā tēma ir vienkārša: pircēja organizācijai jāzina, ko tā pērk, kādu risku tā importē un kādus pierādījumus tā var sniegt, kad tos pieprasa regulatori, klienti vai auditori.

ISO 27001 kontroles pasākumu mugurkauls piegādātāju drošības apliecinājumam

Efektīvākais drošības prasībās balstīta iepirkuma modelis netiek būvēts pa vienam regulējumam. Tas sākas ar kontroles pasākumiem. Clarysec izmanto ISO/IEC 27001:2022 kā IDPS mugurkaulu, ko atbalsta ISO/IEC 27002:2022 kontroles pasākumu vadlīnijas un savstarpējās atbilstības kartēšana Zenith Controls.

Zenith Controls piegādātāju drošības apliecinājums balstās uz ISO/IEC 27002:2022 kontroles pasākumiem 5.19, 5.20 un 5.21. Tie nav izolēti kontrolsaraksta punkti. Tie veido iepirkuma dzīves ciklu.

Zenith Controls kartē šos ISO kontroles pasākumus pret regulatīvajām un audita prasībām. Tas neveido atsevišķus īpašnieka kontroles pasākumus ar nosaukumu Zenith Controls. Tas palīdz komandām saprast, kā ISO/IEC 27002:2022 kontroles pasākumi atbalsta NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT orientētu apliecinājumu.

Svarīgs ir arī atbalstošais kontroles pasākumu tīkls. Piegādātāju drošības apliecinājums sasaistās ar aktīvu pārvaldību, piekļuves kontroli, mākoņdrošību, ievainojamību pārvaldību, žurnalēšanu, incidentu pārvaldību, IKT gatavību darbības nepārtrauktībai, drošu izstrādi, lietojumprogrammu drošību, konfigurāciju pārvaldību, rezerves kopiju veidošanu, redundanci, tiesisko atbilstību, privātumu, izmaiņu pārvaldību un neatkarīgu pārskatīšanu. Iepirkums koordinē procesu, bet atbildībā par risku jāiesaista biznesa īpašnieks, informācijas drošības funkcija, Juridiskais dienests, privātuma funkcija, IT, finanses un pakalpojuma īpašnieks.

Clarysec politikas kontrolpunkti pirms parakstīšanas

Clarysec politiku modelis apzināti pārceļ piegādātāju drošības apliecinājumu agrākā posmā. Stingrākā valoda parādās tur, kur tai jābūt: pirms līgumu parakstīšanas, pirms mākoņpakalpojumu abonementu aktivizēšanas un pirms datu kopīgošanas.

Clarysec Third-Party and Supplier Security Policy SME versijā noteikts:

Izvērtēt un dokumentēt piegādātāju riskus pirms līgumu parakstīšanas vai piekļuves piešķiršanas.

Tas nāk no sadaļas “Mērķi”, politikas punkta 3.3. Punkts ir īss, jo kontroles nolūks nav apspriežams: nav risku izvērtēšanas, nav līguma, nav piekļuves.

Uzņēmuma vidēm Clarysec Third party and supplier security policy pastiprina pirmslīguma kontrolpunktu:

Visiem jaunajiem piegādātājiem pirms līguma noslēgšanas jāiziet dokumentēta drošības izvērtēšana.

Tas nāk no sadaļas “Politikas ieviešanas prasības”, politikas punkta 6.1.1. Tā pati politika sadaļā “Pārvaldības prasības”, politikas punktā 5.3.4, nosaka arī “tiesības auditēt, pārbaudīt un pieprasīt drošības pierādījumus”.

Mākoņpakalpojumu un SaaS iegādei SME Cloud Usage Policy pievieno praktiskus apstiprināšanas kontrolpunktus:

Visa mākoņpakalpojumu izmantošana pirms ieviešanas vai abonēšanas ir jāpārskata un jāapstiprina ģenerāldirektoram (GM).

Tas nāk no sadaļas “Pārvaldības prasības”, politikas punkta 5.1. Mazā organizācijā šis apstiprinājums var būt līdzvērtīgs mākoņpārvaldības padomei. Uzņēmumā tas kļūst par darbplūsmu starp iepirkumu, drošību, privātumu un arhitektūru. Uzņēmuma Cloud Usage Policy atbalsta arī līgumiskās mākoņpakalpojumu prasības, tostarp piemērojamus noteikumus CSP līgumos.

Programmatūras iegādei uzņēmuma Application Security Requirements Policy ir nepārprotama:

Programmatūras iegādes vai ārpakalpojuma vienošanās RFP, līgumos un SLA ir jāietver drošības prasības, tostarp noteikumi par ievainojamību novēršanas termiņiem un trešo pušu audita tiesībām.

Tas nāk no sadaļas “Pārvaldības prasības”, politikas punkta 5.4. Pievērsiet uzmanību secībai: RFP, līgumi un SLA. Drošība parādās tirgus iesaistes posmā, nevis kā pielikums pēc piegādātāja izvēles.

GDPR vadītam iepirkumam Clarysec SME Legal and Regulatory Compliance Policy prasa:

Datu apstrādes līguma (DPA) klauzulas vai līdzvērtīgi līguma noteikumi ir jāsaskaņo pirms jebkādu personas datu vai sensitīvu datu kopīgošanas.

Tas nāk no sadaļas “Politikas ieviešanas prasības”, politikas punkta 6.3.2. Tas novērš vienu no biežākajām SaaS ieviešanas kļūdām: personas datu augšupielādi rīkā, pirms ir saskaņoti apstrādātāja noteikumi, pārkāpuma pienākumi un apakšapstrādātāju nosacījumi.

Piegādātāju lietojumprogrammu drošībai SME Application Security Requirements Policy prasa, lai iepirkums:

norādītu pienākumus attiecībā uz ievainojamību izpaušanu, reaģēšanas laiku un ielāpu ieviešanu.

Tas ir no sadaļas “Pārvaldības prasības”, politikas punkta 5.3.2. Tajā arī noteikts:

GM attiecīgajos gadījumos ir jāpieprasa dokumentācija vai sertifikācijas (piemēram, SOC 2, ISO 27001, drošības testu pārskati) kā piegādātāja atbilstības pierādījumi.

Tas nāk no sadaļas “Politikas ieviešanas prasības”, politikas punkta 6.3.2. Atslēgvārds ir pierādījumi. Drošības prasībās balstīts iepirkums nebalstās uz uzticēšanās paziņojumiem. Tas balstās uz pārskatāmiem artefaktiem.

Zenith Blueprint iepirkuma kontrolpunkti

Zenith Blueprint piegādātāju drošību uztver kā operacionalizētu kontroles pasākumu, nevis iepirkuma saukli. Fāzē Controls in Action Step 23 aptver organizatoriskās kontroles 5.19 līdz 5.37, tostarp informācijas drošību attiecībās ar piegādātājiem.

Blueprint skaidro:

Tas sākas ar piegādātāja klasifikāciju. Ne visi piegādātāji rada vienādu risku. Uzkopšanas pakalpojumu sniedzējam var būt fiziska piekļuve birojiem, bet ne tīkliem. Savukārt ielaušanās testēšanas uzņēmumam vai mākoņmitināšanas pakalpojumu sniedzējam var būt dziļa tehniska piekļuve pašam jūsu infrastruktūras kodolam. Klasifikācijā jāņem vērā, vai piegādātājs tieši apstrādā jūsu informāciju, vai tas nodrošina infrastruktūru vai platformas, uz kurām jūs darbojaties, vai tas jūsu vārdā pārvalda vai uztur sistēmas un vai tā kompromitēšana varētu ietekmēt jūsu konfidencialitātes, integritātes vai pieejamības mērķus.

Attiecībā uz kontroles pasākumu 5.20 Blueprint ir tiešs:

Galvenās jomas, kas parasti tiek risinātas piegādātāju līgumos, ietver konfidencialitātes pienākumus; piekļuves kontroles atbildības; tehniskos un organizatoriskos pasākumus datu aizsardzībai, šifrēšanai, drošai pārsūtīšanai, rezerves kopiju veidošanai un pieejamības saistībām; incidentu ziņošanas termiņus un protokolus; audita tiesības, tostarp biežumu, darbības jomu un piekļuvi attiecīgajiem pierādījumiem; apakšuzņēmēju kontroles pasākumus; un līguma beigu noteikumus, piemēram, datu atdošanu vai iznīcināšanu, aktīvu atgūšanu un kontu deaktivizēšanu.

Tajā secināts, ka kontroles pasākums 5.20 ir “jūsu pēdējā ietekmes līnija” un “tam jāatrodas iepirkuma kontrolpunktā”. Kad līgums ir parakstīts, ietekmes iespējas samazinās. Pirms parakstīšanas pierādījumus un pienākumus var noteikt kā pirkuma nosacījumus.

Ārpakalpojuma izstrādei fāzē Controls in Action Step 21, kontroles pasākums 8.30, pievieno vēl vienu iepirkuma prasību. Blueprint norāda:

Šī kontroles pasākuma pamatā ir princips, ka drošībai jābūt līgumiskai prasībai, nevis mutiskai gaidai.

Ārpakalpojuma komandām jāpiemēro tie paši drošas izstrādes standarti kā iekšējām komandām, tostarp statiskā analīze, līdzinieku pārskatīšana, šifrēšana, MFA piekļuve repozitorijiem un redzamība pār kodu, arhitektūras lēmumiem, ievainojamībām, izmaiņu pieprasījumiem, CI/CD žurnāliem un skenēšanas rezultātiem.

Izveidojiet drošības prasībās balstītus RFP kontrolpunktus vienā pēcpusdienā

Pieņemsim, ka jūsu organizācija vēlas klientu analītikas platformu. Tā uzņems klientu identifikatorus, uzvedības notikumus, atbalsta metadatus un darījumu atsauces. Biznesa īpašnieks vēlas ātru apstiprinājumu. Drošības komandai ir viena nedēļa.

Sāciet ar iepirkuma kontrolpunkta ierakstu, kā avota dokumentus izmantojot Third party and supplier security policy, Application Security Requirements Policy, Cloud Usage Policy, Legal and Regulatory Compliance Policy un Zenith Blueprint Step 23.

Pievienojiet RFP drošības prasībās balstītu anketu. Izvairieties no vispārīgiem jautājumiem, piemēram, “Vai jūs šifrējat datus?” Uzdodiet uz pierādījumiem balstītus jautājumus:

1. Iesniedziet savu pašreizējo neatkarīgo drošības apliecinājuma pārskatu, sertifikātu vai līdzvērtīgus kontroles pierādījumus.
2. Norādiet mitināšanas vietas, datu rezidences iespējas, rezerves kopiju atrašanās vietas un atbalsta piekļuves vietas.
3. Iesniedziet DPA, apakšapstrādātāju sarakstu un paziņošanas procesu apakšapstrādātāju izmaiņām.
4. Apstipriniet incidentu paziņošanas termiņus, tostarp 24 stundu agrīnā brīdinājuma atbalstu gadījumos, kad var tikt ierosinātas NIS2 darbplūsmas, un pakāpeniskas ziņošanas atbalstu DORA regulētiem klientiem.
5. Iesniedziet ievainojamību izpaušanas politiku, ielāpu SLA pēc smaguma pakāpes un pierādījumus par nesenu ievainojamību novēršanas pārvaldību.
6. Iesniedziet produkta drošības pierādījumus, piemēram, drošas izstrādes dzīves cikla aprakstu, ielaušanās testēšanas kopsavilkumu, SBOM vai komponentu pārredzamības paziņojumu un drošības atjauninājumu atbalsta periodu.
7. Apstipriniet MFA, minimāli nepieciešamās tiesības, žurnalēšanu, administratīvās piekļuves uzraudzību un klienta audita vai pierādījumu pieprasīšanas tiesības.
8. Aprakstiet eksportu, dzēšanu, atdošanu, izbeigšanas atbalstu un pārejas palīdzību.
9. Uzskaitiet būtiskos apakšuzņēmējus un IKT atkarības, kas atbalsta pakalpojumu.
10. Apstipriniet, vai klientu dati tiek izmantoti apmācībai, analītikai, produkta uzlabošanai vai AI modeļu izstrādei, un identificējiet tiesisko pamatu vai apstrādātāja norādījumu modeli.

Pēc tam novērtējiet piegādātāju pirms sarunām.

Visbeidzot atjauniniet Riska reģistru un piemērojamības deklarāciju. Riska apstrādes ierakstam jāparāda, kāpēc piemērojami ISO/IEC 27002:2022 kontroles pasākumi 5.19, 5.20 un 5.21, kuras līgumiskās un tehniskās prasības tika atlasītas, kam pieder atlikušais risks un kāds uzraudzības ritms piemērojams. Ja bizness vēlas turpināt, neskatoties uz trūkumiem, izmantojiet formālu riska pieņemšanas ierakstu ar beigu datumu, kompensējošajiem kontroles pasākumiem un augstākās vadības apstiprinājumu.

Līguma klauzulas, kas pārvērš regulējumu izpildāmās saistībās

Drošības prasībām jākļūst par līgumiskām saistībām. Sertifikāts var būt noderīgs, taču tas reti atbild uz visiem jautājumiem par tieši jūsu pakalpojumu, datu atrašanās vietu, apakšuzņēmējiem, atbalsta modeli, incidentu saistībām vai izstāšanās tiesībām.

Šī tabula ir praktiskais tilts starp juridiskajiem pienākumiem un iepirkuma darbu. Tā palīdz arī Juridiskajam dienestam, drošībai un iepirkumam vest sarunas no vienas kontroles pamatlīnijas.

Savstarpējās atbilstības kartēšana: viena piegādātāja lieta, daudzi pienākumi

ISO/IEC 27001:2022 izmantošanas kā mugurkaula priekšrocība ir tā, ka viena piegādātāja drošības apliecinājuma lieta var atbalstīt vairākas regulatīvās sarunas.

NIST CSF 2.0 ir noderīgs kā komunikācijas slānis. Tā GOVERN funkcija uzsver juridisko, regulatīvo, līgumisko, privātuma un atkarību izpratni. Tā GV.SC piegādes ķēdes rezultāti prasa piegādes ķēdes risku pārvaldības procesus, piegādātāju lomas, piegādātāju prioritizēšanu pēc kritiskuma, līgumiskās prasības, sākotnējo izpēti, uzraudzību, incidentu plānošanu un izbeigšanas plānošanu.

Tas precīzi kartējas uz Zenith Blueprint Step 23 un ISO/IEC 27002:2022 kontroles pasākumiem 5.19 līdz 5.21, kā kartēts Zenith Controls. Tas arī dod valdēm saprotamu valodu: pašreizējais stāvoklis, mērķa stāvoklis, trūkums, risks, darbība, īpašnieks un datums.

Ko jautās auditori

Spēcīgam drošības prasībās balstītam iepirkuma procesam jāiztur dažādi audita skatījumi.

ISO/IEC 27001:2022 auditors sāks ar IDPS kontekstu un darbības jomu. Viņš jautās, vai piegādātāju saskarnes un atkarības ir iekļautas, vai ieinteresēto pušu prasībās ietilpst NIS2, DORA, GDPR un klientu līgumi, un vai piegādātāju riski tiek konsekventi izvērtēti saskaņā ar riska metodoloģiju. Viņš sekos audita pēdai uz riska apstrādi, piemērojamības deklarāciju, piegādātāju kontroles pasākumiem, darbības pierādījumiem, iekšējo auditu un vadības pārskatīšanu.

DORA pārskatītājs koncentrēsies uz IKT atbalstītām biznesa funkcijām, kritiskām vai svarīgām funkcijām, trešo pušu atkarību ierakstiem, līguma klauzulām, audita un piekļuves tiesībām, sadarbību incidentu gadījumā, noturības testēšanu, izstāšanās stratēģijām un koncentrācijas risku. Ja SaaS atbalsta kritisku vai svarīgu funkciju, ar vienkāršu piegādātāja anketu nepietiks.

NIS2 iestāde jautās, kā organizācija izvērtēja piegādātāju kiberdrošības prakses, tiešo piegādātāju ievainojamības, incidentu paziņošanas atbalstu, nepārtrauktības atkarības un drošas iegādes lēmumus. Tā pārbaudīs, vai piegādātāju drošības apliecinājums atbalsta pašas organizācijas Article 21 un Article 23 pienākumus.

GDPR pārskatītājs jautās, vai pārziņa un apstrādātāja lomas bija izprastas pirms apstrādes sākuma, vai DPA vai līdzvērtīgi noteikumi tika saskaņoti pirms datu kopīgošanas, vai apakšapstrādātāji tika atklāti, vai drošības pasākumi bija atbilstoši, vai sadarbība pārkāpuma gadījumā ir līgumiska un vai datu atdošana vai dzēšana ir izpildāma.

COBIT 2019 vai ISACA stila auditors koncentrēsies uz pārvaldību un pārskatatbildību: kurš apstiprināja piegādātāju, kurš risks tika pieņemts, vai tika ievērotas politikas prasības, vai izņēmumi tiek izsekoti un vai ieguvumi, risks un resursi tika līdzsvaroti.

Jūsu pierādījumu paketē jāiekļauj piegādātāja klasifikācija, biznesa īpašnieka apstiprinājums, risku izvērtēšana, RFP drošības prasības, piegādātāja atbildes, DPA, drošības pielikums, SLA, audita tiesības, apakšapstrādātāju reģistrs, ievainojamību saistības, incidentu klauzulas, mākoņvides atrašanās vietas pierādījumi, žurnalēšanas un šifrēšanas pierādījumi, izstāšanās noteikumi, atkārtotas izvērtēšanas ieraksti, izņēmumi un piemērojamības deklarācijas kartējums.

Biežākie kļūdu modeļi programmatūras iegādē

Pirmā kļūda ir uztvert iepirkumu kā komerciālu darbplūsmu un drošību kā tehnisku darbplūsmu. Brīdī, kad drošība saņem līgumu, bizness jau ir psiholoģiski apņēmies, ieviešanas datums ir paziņots un sarunu ietekme ir vāja.

Otrā kļūda ir pierādījumu aizstāšana. Piegādātājs iesniedz sertifikātu, un pircējs pieņem, ka tas atbild uz visiem jautājumiem. Sertifikācija var palīdzēt, taču tā var neaptvert konkrēto produktu, mitināšanas reģionu, atbalsta modeli, apakšuzņēmēju ķēdi, incidentu pienākumus, AI datu izmantošanu vai izstāšanās prasības.

Trešā kļūda ir pakārtotā riska ignorēšana. SaaS piegādātājs var paļauties uz mākoņmitināšanu, analītikas rīkiem, atbalsta platformām, ārvalstu izstrādes komandām, AI modeļu sniedzējiem un maksājumu apstrādātājiem. ISO/IEC 27002:2022 kontroles pasākums 5.21 prasa pievērst uzmanību IKT piegādes ķēdei aiz tiešā piegādātāja. DORA kontekstā tas sasaistās ar apakšuzņēmēju izmantošanu un koncentrācijas risku. GDPR kontekstā tas sasaistās ar apakšapstrādātājiem. NIS2 kontekstā tas sasaistās ar tiešo piegādātāju ievainojamībām un piegādātāju kiberdrošības praksēm.

Ceturtā kļūda ir vāja incidentu valoda. Līgums, kurā teikts “piegādātājs nekavējoties informēs klientu”, var neatbalstīt NIS2 agrīno brīdinājumu, DORA pakāpenisko ziņošanu, klientu komunikāciju vai iekšējo eskalāciju. Incidentu klauzulām ir nepieciešami termiņi, trigeri, kontaktpersonas, sadarbības pienākumi un pierādījumu pienākumi.

Piektā kļūda ir neskaidras izstāšanās tiesības. Ja piegādātājs kļūst nedrošs, neatbilstošs, tiek iegādāts, kļūst maksātnespējīgs vai stratēģiski nepiemērots, pircējam ir nepieciešams eksports, dzēšana, pārejas atbalsts, kontu deaktivizēšana un iznīcināšanas pierādījumi. Izstāšanās nav juridiska pēcpārdomu detaļa. Tā ir noturības kontrole.

No iepirkuma kontrolpunktiem līdz dzīvam piegādātāju drošības apliecinājumam

Drošības prasībās balstīts iepirkums nebeidzas pie paraksta. Nobriedušam Clarysec stila piegādātāju dzīves ciklam ir pieci posmi.

Augsta riska piegādātājiem uzraudzībā jāiekļauj pierādījumu atjaunošana, drošības pārskatīšanas sanāksmes, dalība incidentu galda vingrinājumos, piekļuves tiesību pārskatīšana, ievainojamību un ielāpu ziņošana, pakalpojuma izmaiņu pārskatīšana un apakšapstrādātāju atjauninājumi. Zemāka riska piegādātājiem var pietikt ar ikgadēju pārskatīšanu. ISO 27001 mērogojamība, NIS2 proporcionalitāte un DORA proporcionalitāte atbalsta pielāgošanu, taču pielāgošana ir jāpamato un jādokumentē.

Nākamais Clarysec solis

Nākamais riskantais SaaS pirkums negaidīs ideālu pārvaldības pārveidi. Sāciet ar nākamo iepirkuma pieprasījumu.

Izmantojiet Zenith Blueprint: An Auditor’s 30-Step Roadmap, lai ieviestu Step 23 piegādātāju attiecību kontroles pasākumus un Step 21 ārpakalpojuma izstrādes kontroles pasākumus. Izmantojiet Zenith Controls, lai kartētu ISO/IEC 27002:2022 kontroles pasākumus 5.19, 5.20 un 5.21 pret NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT orientētām audita prasībām. Izmantojiet Clarysec politiku bibliotēku, tostarp Third party and supplier security policy, Application Security Requirements Policy, Cloud Usage Policy un Legal and Regulatory Compliance Policy, lai padarītu kontrolpunktus izpildāmus.

Pirms nākamā līguma parakstīšanas pieprasiet piegādātāja klasifikāciju, drošības pierādījumus, DPA gatavību, incidentu saistības, ievainojamību pārvaldību, apakšuzņēmēju pārredzamību, audita tiesības un izstāšanās noteikumus.

Tas ir drošības prasībās balstīts iepirkums. Tas CISO regulatīvo spiedienu pārvērš iepirkuma ietekmē. Tas atbilstības vadītājiem ļauj pārklājošus pienākumus pārvērst vienā pierādījumu lietā. Tas auditoriem parāda, ka piegādātāja risks tika izvērtēts pirms atkarības izveides. Un tas biznesa īpašniekiem ļauj iegādāties programmatūru ātrāk, nepārmantojot nepārvaldītu risku.

Vai esat gatavi pārvērst nākamo programmatūras pirkumu auditam gatavā kontroles pasākumā? Izpētiet Clarysec integrēto politiku komplektu, lejupielādējiet Zenith Blueprint, pārskatiet Zenith Controls vai ieplānojiet demonstrāciju, lai izveidotu drošības prasībās balstītu iepirkuma programmu, kas iztur NIS2, DORA, GDPR, CRA prasības un reālu auditoru pārbaudi.