Secure-by-demand-ohjelmistohankinta vuonna 2026

On tiistaiaamu vuoden 2026 alussa, ja Maria, nopeasti kasvavan eurooppalaisen maksuyhtiön tietoturvajohtaja, esittelee asiaa hallitukselle. Esityslistan viimeisen kohdan pitäisi olla rutiininomainen: uuden tekoälyä hyödyntävän petostentorjunta-alustan hyväksyntä. Toimittajalla on vaikuttava demo, määräaikainen alennus, yhden sivun tietoturvayhteenveto ja vakiosopimus.

Sitten kysymykset alkavat.

Toimitusjohtaja kysyy: “Mistä tiedämme, että tämä alusta on turvallinen? Finanssipalveluasiakkaamme pyytävät DORA-vaatimustenmukaisuusnäyttöä, ja tästä toimittajasta tulee osa kriittistä infrastruktuuriamme.”

Lakitoiminto kysyy, onko tietojenkäsittelysopimus valmis, missä EU-asiakkaiden tietoja käsitellään ja onko alikäsittelijät ilmoitettu. Operatiivisesta häiriönsietokyvystä vastaava henkilö kysyy irtautumissuunnittelusta, varmuuskopioiden viennistä ja kriittisten toimintojen jatkuvuudesta. Tuoteturvallisuusinsinööri pyytää haavoittuvuuksien julkistusmenettelyä, korjausnäyttöä ja SBOMia tai vastaavaa lausumaa komponenttiläpinäkyvyydestä. Hankinta esittää kysymyksen, joka tekee toimittajariskistä kalliin: “Voimmeko hyväksyä nyt ja kerätä asiakirjat allekirjoituksen jälkeen?”

Tässä kohdassa nykyaikaisesta ohjelmistohankinnasta tulee joko hallintakeino tai tuleva poikkeamaraportti.

Vuonna 2026 turvallinen ohjelmistohankinta ei voi perustua sopimuksen jälkeiseen hyväntahtoisuuteen. NIS2:n toimitusketjun tietoturva, DORA:n ICT-kolmansien osapuolten riski, GDPR:n henkilötietojen käsittelijää koskeva osoitusvelvollisuus ja Cyber Resilience Act -säädöksen tuoteturvallisuusodotukset ovat siirtäneet toimittajien varmentamisen hankintapäätöksen yhteyteen. Ostajat tarvitsevat secure-by-demand-ohjelmistohankintaa, jossa asiakas määrittää tietoturvanäytön, sopimuslausekkeet, käyttöönottoportit ja operatiiviset vastuut ennen hankintaa.

Clarysecin asiakkaille vastaus ei ole jälleen uusi taulukko, joka kuolee sähköpostiketjuun. Vastaus on ISO/IEC 27001:2022 -standardin mukainen hankinnan hallintakehikko, joka on kartoitettu Clarysecin politiikkojen, Zenith Blueprint: auditoijan 30 vaiheen tiekartan ja Zenith Controls avulla niin, että jokaisella ohjelmisto- tai SaaS-hankinnalla on puolustettavissa oleva jälki liiketoimintatarpeesta toimittajariskipäätökseen.

Secure-by-demand on uusi ohjelmistohankinnan hallintakeino

Secure-by-design käsitellään yleensä toimittajan näkökulmasta. Secure-by-demand on ostajan toimintakuri: organisaatio kieltäytyy ostamasta ohjelmistoa, ellei toimittaja pysty osoittamaan, että tietoturva, tietosuoja, häiriönsietokyky, haavoittuvuuksien käsittely ja auditoitavuus sisältyvät tarjontaan.

Tämä muuttaa hankintakeskustelun. Sen sijaan, että hankinta kysyisi “Onko teillä tietoturvaa?”, se esittää täsmällisempiä kysymyksiä:

• Mitä tietoja käsittelette, missä ja missä oikeudellisessa roolissa?
• Mihin liiketoimintatoimintoon teistä syntyy riippuvuus, ja kuinka kriittinen se on?
• Mikä näyttö osoittaa, että hallintakeinonne toimivat eivätkä ole vain dokumentoituja?
• Mihin poikkeamailmoitusten määräaikoihin sitoudutte?
• Mitä näyttöä voitte toimittaa haavoittuvuuksien julkistamisesta, korjaamisesta, SBOMista tai VEXistä?
• Mitkä alihankkijat tai alikäsittelijät käsittelevät tietojamme tai palveluamme?
• Voimmeko auditoida, tarkastaa tai pyytää näyttöä sopimuskauden aikana?
• Mitä tapahtuu sopimuksen päättyessä, migraatiossa, tietoturvaloukkauksessa, maksukyvyttömyydessä tai viranomaistiedustelussa?

ISO/IEC 27001:2022 antaa tälle muutokselle johtamisjärjestelmän perustan. Lauseke 4 edellyttää, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmänsä ja ISMS:n soveltamisalan, mukaan lukien ulkoiset sääntely- ja toimittajavaatimukset. Lauseke 5 muuttaa toimittajariskin johdon ja hallinnon vastuuksi. Lauseke 6 edellyttää riskien arviointia, riskien käsittelyä, hallintakeinojen valintaa, soveltuvuuslausuntoa ja jäännösriskipäätöksiä. Lauseke 8 edellyttää prosessien hallittua toimintaa, myös ulkoisesti tuotettujen prosessien osalta. Lauseke 9 edellyttää seurantaa, sisäistä auditointia ja johdon katselmointia.

Tämä tarkoittaa, että ohjelmistohankinta ei ole vain kaupallinen työnkulku. Siitä tulee käytössä oleva ja auditoitavissa oleva ISMS-prosessi. Sääntelyviranomaiset ja auditoijat kysyvät yhä useammin, miksi organisaatio hyväksyi toimittajan ennen kuin se ymmärsi riskin. Secure-by-demand-hankinta antaa selkeän vastauksen: riski arvioitiin, käsiteltiin, sopimuksellistettiin ja vastuutettiin ennen riippuvuuden muodostumista.

Miksi NIS2, DORA, GDPR ja CRA kohtaavat toimittajavalinnassa

Marian hallitus esittää oikeita kysymyksiä, koska yksi ohjelmistotoimittaja voi laukaista useita velvoitteita samanaikaisesti.

NIS2 soveltuu toimialan, koon ja kriittisyyden perusteella, ja Annex I ja Annex II tuovat soveltamisalaan monia digitaalisia, finanssialan, infrastruktuuriin liittyviä, hallinnoituja palveluja tuottavia ja pilvipalveluista riippuvaisia organisaatioita. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien toimitusketjun tietoturva, turvallinen hankinta, turvallinen kehittäminen ja ylläpito, haavoittuvuuksien käsittely, pääsynhallinta, omaisuudenhallinta, jatkuvuus, poikkeamien käsittely ja hallintakeinojen tehokkuuden arviointi. Article 21(3) edellyttää erityisesti huomiota suorien toimittajien haavoittuvuuksiin ja toimittajien kyberturvallisuuskäytäntöihin. Article 23 luo vaiheistetut merkittävien poikkeamien raportointiodotukset, mukaan lukien ennakkovaroitus 24 tunnin kuluessa ja ilmoitus 72 tunnin kuluessa.

DORA soveltuu 17.1.2025 alkaen soveltamisalaan kuuluviin finanssialan toimijoihin. Se luo yhdenmukaiset vaatimukset ICT-riskien hallinnalle, ICT:hen liittyvien poikkeamien raportoinnille, digitaalisen operatiivisen häiriönsietokyvyn testaukselle ja ICT-kolmansien osapuolten riskienhallinnalle. DORA on erityisen määräävä hankinnan osalta. Finanssialan toimijat tarvitsevat ICT-kolmansien osapuolten riskistrategiat, ICT-palvelujärjestelyjen rekisterit, due diligence -arvioinnin, keskittymäriskin analyysin, kirjalliset sopimukset tietoturva- ja häiriönsietokykyvaatimuksineen, auditointi- ja pääsyoikeudet, yhteistyövelvoitteet, päättämisoikeudet ja irtautumissuunnitelmat. Articles 28 ja 30 ovat keskeisiä ICT-kolmansien osapuolten riskin ja sopimuksellisten hallintakeinojen kannalta, kun taas Articles 17–23 ohjaavat poikkeamien hallintaa ja raportointia.

GDPR lisää portin henkilötietojen käsittelijöitä koskevalle osoitusvelvollisuudelle. Articles 5, 28, 32, 33 ja 34 edellyttävät osoitusvelvollisuutta, henkilötietojen käsittelijäsopimuksia, asianmukaista turvallisuutta, yhteistyötä henkilötietojen tietoturvaloukkauksista ilmoittamisessa ja rekisteröityihin kohdistuvien vaikutusten käsittelyä. SaaS-toimittaja, joka käsittelee henkilötietoja, ei ole pelkkä toimittaja. Siitä tulee osa rekisterinpitäjän vaatimustenmukaisuusasemaa. DPA, tekniset ja organisatoriset toimenpiteet, alikäsittelijäluettelo, siirron suojatoimet, säilytyssäännöt ja poistovelvoitteet on ymmärrettävä ennen käsittelyn aloittamista.

CRA-odotukset lisäävät tuotteen varmentamisen. Vaikka ostaja ei olisi valmistaja, hankintatiimien on syytä vaatia näyttöä turvallisesta kehittämisestä, haavoittuvuuksien käsittelystä, tuotetuesta, tietoturvapäivityksistä, haavoittuvuuksien koordinoidusta julkistamisesta ja komponenttiläpinäkyvyydestä, kuten SBOMista tai vastaavasta lausumasta. Nämä vaatimukset kuuluvat tarjouspyyntöihin, tietoturvaliitteisiin ja hyväksyntäportteihin.

Yhteinen teema on yksinkertainen: ostavan organisaation on tiedettävä, mitä se ostaa, minkä riskin se tuo sisään ja mitä näyttöä se pystyy tuottamaan, kun sääntelyviranomaiset, asiakkaat tai auditoijat kysyvät.

ISO 27001 -hallintakehikko toimittajien varmentamiseen

Tehokkain secure-by-demand-hankintamalli ei etene säädös kerrallaan. Se on hallintakeinolähtöinen. Clarysec käyttää ISO/IEC 27001:2022 -standardia ISMS:n runkona, jota tukevat ISO/IEC 27002:2022 -hallintakeino-ohjeistus ja Zenith Controls -ratkaisun ristiinvaatimustenmukaisuuden kartoitus.

Zenith Controls ankkuroi toimittajien varmentamisen ISO/IEC 27002:2022 -hallintakeinoihin 5.19, 5.20 ja 5.21. Ne eivät ole irrallisia tarkistuslistakohtia. Ne muodostavat hankinnan elinkaaren.

Zenith Controls kartoittaa nämä ISO-hallintakeinot sääntely- ja auditointiodotuksiin. Se ei luo erillisiä omia hallintakeinoja nimeltä Zenith Controls. Se auttaa tiimejä ymmärtämään, miten ISO/IEC 27002:2022 -hallintakeinot tukevat NIS2-, DORA-, GDPR-, NIST CSF 2.0 - ja COBIT-suuntautunutta varmentamista.

Myös tukeva hallintakeinoverkosto on tärkeä. Toimittajien varmentaminen liittyy omaisuudenhallintaan, pääsynhallintaan, pilviturvallisuuteen, haavoittuvuuksien hallintaan, lokitukseen, poikkeamien hallintaan, liiketoiminnan jatkuvuutta tukevaan ICT-valmiuteen, turvalliseen kehittämiseen, sovellusturvallisuuteen, konfiguraationhallintaan, varmuuskopiointiin, redundanssiin, lain- ja sääntelyvaatimusten noudattamiseen, tietosuojaan, muutoksenhallintaan ja riippumattomaan katselmointiin. Hankinta koordinoi prosessia, mutta riskinomistajuuteen on sisällytettävä liiketoimintavastaava, tietoturva, lakiasiat, tietosuoja, IT, taloushallinto ja palveluomistaja.

Clarysecin politiikkaportit ennen allekirjoitusta

Clarysecin politiikkamalli siirtää toimittajien varmentamisen tarkoituksellisesti ylävirtaan. Vahvin velvoittava kieli on siellä, missä sen pitääkin olla: ennen sopimusten allekirjoittamista, ennen pilvitilausten aktivointia ja ennen tietojen jakamista.

Clarysecin Kolmansien osapuolten ja toimittajien tietoturvapolitiikan pk-yritysversiossa todetaan:

Arvioi ja dokumentoi toimittajariskit ennen sopimusten allekirjoittamista tai käyttöoikeuden myöntämistä.

Tämä on peräisin osiosta “Tavoitteet”, politiikan lausekkeesta 3.3. Lauseke on lyhyt, koska hallintakeinon tarkoitus on neuvottelematon: ei riskien arviointia, ei sopimusta, ei käyttöoikeutta.

Yritysympäristöissä Clarysecin Kolmansien osapuolten ja toimittajien tietoturvapolitiikka vahvistaa sopimusta edeltävän portin:

Kaikille uusille toimittajille on tehtävä dokumentoitu tietoturva-arviointi ennen sopimuksen täytäntöönpanoa.

Tämä on peräisin osiosta “Politiikan toteutusvaatimukset”, politiikan lausekkeesta 6.1.1. Sama politiikka tunnistaa myös “oikeudet auditoida, tarkastaa ja pyytää tietoturvanäyttöä” osiossa “Hallinnointivaatimukset”, politiikan lausekkeessa 5.3.4.

Pilvi- ja SaaS-hankinnoissa pk-yrityksille tarkoitettu Pilvipalvelujen käyttöpolitiikka lisää käytännöllisen hyväksyntäportin:

Toimitusjohtajan (GM) on katselmoitava ja hyväksyttävä kaikki pilvipalvelujen käyttö ennen toteutusta tai tilausta.

Tämä on peräisin osiosta “Hallinnointivaatimukset”, politiikan lausekkeesta 5.1. Pienessä organisaatiossa tämä hyväksyntä voi vastata pilvihallinnon toimielintä. Yritysympäristössä siitä tulee työnkulku hankinnan, tietoturvan, tietosuojan ja arkkitehtuurin välillä. Yritystason Pilvipalvelujen käyttöpolitiikka tukee myös sopimuksellisia pilvivaatimuksia, mukaan lukien täytäntöönpantavat ehdot pilvipalveluntarjoajien sopimuksissa.

Ohjelmistojen hankinnassa yritystason Sovellusturvallisuusvaatimusten politiikka on täsmällinen:

Ohjelmistohankintoihin tai ulkoistusjärjestelyihin on sisällytettävä tietoturvavaatimukset tarjouspyyntöihin, sopimuksiin ja SLA-sopimuksiin, mukaan lukien määräykset haavoittuvuuksien korjaamisen määräajoista ja kolmansien osapuolten auditointioikeuksista.

Tämä on peräisin osiosta “Hallinnointivaatimukset”, politiikan lausekkeesta 5.4. Huomaa järjestys: tarjouspyynnöt, sopimukset ja SLA-sopimukset. Tietoturva tulee mukaan markkinavuoropuhelun vaiheessa, ei hankintapäätöksen jälkeisenä liitteenä.

GDPR-ohjautuvassa hankinnassa Clarysecin pk-yrityksille tarkoitettu Lain- ja sääntelyvaatimusten noudattamisen politiikka edellyttää:

Tietojenkäsittelysopimuksen (DPA) lausekkeista tai vastaavista sopimusehdoista on sovittava ennen henkilötietojen tai arkaluonteisten tietojen jakamista.

Tämä on peräisin osiosta “Politiikan toteutusvaatimukset”, politiikan lausekkeesta 6.3.2. Tämä estää yhden yleisimmistä SaaS-käyttöönoton epäonnistumisista: henkilötietojen lataamisen työkaluun ennen kuin henkilötietojen käsittelijää koskevista ehdoista, tietoturvaloukkausvelvoitteista ja alikäsittelijöitä koskevista ehdoista on sovittu.

Toimittajien sovellusturvallisuuden osalta pk-yrityksille tarkoitettu Sovellusturvallisuusvaatimusten politiikka edellyttää hankinnalta, että se:

määrittää velvoitteet haavoittuvuuksien julkistamiselle, vasteajoille ja korjaamiselle.

Tämä on peräisin osiosta “Hallinnointivaatimukset”, politiikan lausekkeesta 5.3.2. Politiikassa todetaan myös:

Toimitusjohtajan on pyydettävä dokumentaatiota tai sertifiointeja (esim. SOC 2, ISO 27001, tietoturvatestiraportit) toimittajan vaatimustenmukaisuuden näyttönä soveltuvin osin.

Tämä on peräisin osiosta “Politiikan toteutusvaatimukset”, politiikan lausekkeesta 6.3.2. Avainsana on näyttö. Secure-by-demand-hankinta ei perustu luottamusväittämiin. Se perustuu katselmoitaviin artefakteihin.

Zenith Blueprintin hankintaportti

Zenith Blueprint käsittelee toimittajaturvallisuutta käytössä olevana hallintakeinona, ei hankinnan iskulauseena. Hallintakeinot käytännössä -vaiheen vaihe 23 kattaa organisatoriset hallintakeinot 5.19–5.37, mukaan lukien tietoturvan toimittajasuhteissa.

Blueprint selittää:

Se alkaa toimittajaluokittelusta. Kaikki toimittajat eivät aiheuta samaa riskiä. Siivouspalvelulla voi olla fyysinen pääsy toimistoihin, mutta ei verkkoihin. Penetraatiotestausyrityksellä tai pilvipalveluntarjoajalla taas voi olla syvä tekninen pääsy infrastruktuurisi ytimeen. Luokittelussa tulisi arvioida, käsitteleekö toimittaja tietojasi suoraan, tarjoaako se infrastruktuuria tai alustoja, joiden varassa toimit, hallinnoiko tai ylläpitääkö se järjestelmiä puolestasi ja voiko sen vaarantuminen vaikuttaa luottamuksellisuutta, eheyttä tai saatavuutta koskeviin tavoitteisiisi.

Hallintakeinon 5.20 osalta Blueprint on suora:

Toimittajasopimuksissa tyypillisesti käsiteltäviä keskeisiä alueita ovat luottamuksellisuusvelvoitteet, pääsynhallintavastuut, tekniset ja organisatoriset toimenpiteet tietosuojalle, salaukselle, turvalliselle siirrolle, varmuuskopioinnille ja saatavuussitoumuksille, poikkeamien raportoinnin aikataulut ja protokollat, auditointioikeus mukaan lukien tiheys, laajuus ja pääsy relevanttiin näyttöön, alihankkijahallintakeinot sekä sopimuksen päättymistä koskevat määräykset, kuten tietojen palautus tai tuhoaminen, omaisuuden palautus ja tilien poistaminen käytöstä.

Se toteaa, että hallintakeino 5.20 on “viimeinen vaikutuskeinonne” ja “kuuluu hankintaportille”. Kun sopimus on allekirjoitettu, neuvotteluvoima heikkenee. Ennen allekirjoitusta näyttö ja velvoitteet voidaan asettaa hankinnan ehdoiksi.

Ulkoistetun kehittämisen osalta Hallintakeinot käytännössä -vaiheen vaihe 21, hallintakeino 8.30, lisää toisen hankintavaatimuksen. Blueprint toteaa:

Tämän hallintakeinon ytimessä on periaate, että tietoturvan on oltava sopimusvaatimus, ei suullinen odotus.

Ulkoistettujen tiimien on täytettävä samat turvallisen kehittämisen standardit kuin sisäisten tiimien, mukaan lukien staattinen analyysi, vertaiskatselmointi, salaus, MFA pääsyssä tietovarastoihin sekä näkyvyys koodiin, arkkitehtuuripäätöksiin, haavoittuvuuksiin, muutospyyntöihin, CI/CD-lokeihin ja skannaustuloksiin.

Rakenna secure-by-demand-tarjouspyyntöportti yhdessä iltapäivässä

Oletetaan, että organisaatiosi haluaa asiakasanalytiikka-alustan. Se vastaanottaa asiakastunnisteita, käyttäytymistapahtumia, tuen metatietoja ja tapahtumaviitteitä. Liiketoimintavastaava haluaa nopean hyväksynnän. Tietoturvatiimillä on yksi viikko.

Aloita hankintaportin tallenteesta käyttäen lähdeasiakirjoina Kolmansien osapuolten ja toimittajien tietoturvapolitiikkaa, Sovellusturvallisuusvaatimusten politiikkaa, Pilvipalvelujen käyttöpolitiikkaa, Lain- ja sääntelyvaatimusten noudattamisen politiikkaa sekä Zenith Blueprintin vaihetta 23.

Liitä tarjouspyyntöön secure-by-demand-kysely. Vältä yleisiä kysymyksiä, kuten “Salaatteko tiedot?” Esitä näyttöön perustuvia kysymyksiä:

1. Toimittakaa nykyinen riippumaton tietoturvavarmennusraportti, sertifikaatti tai vastaava hallintakeinonäyttö.
2. Yksilöikää palvelinympäristöjen sijainnit, tietojen sijaintivaihtoehdot, varmuuskopiointisijainnit ja tuen pääsysijainnit.
3. Toimittakaa DPA, alikäsittelijäluettelo ja ilmoitusprosessi alikäsittelijämuutoksille.
4. Vahvistakaa poikkeamailmoitusten määräajat, mukaan lukien 24 tunnin ennakkovaroituksen tuki tilanteissa, joissa NIS2-työnkulut voivat käynnistyä, sekä vaiheistetun raportoinnin tuki DORA-säännellyille asiakkaille.
5. Toimittakaa haavoittuvuuksien julkistuspolitiikka, vakavuusperusteiset korjaamisen SLA:t ja näyttö viimeaikaisesta haavoittuvuuksien korjaamisen hallinnoinnista.
6. Toimittakaa tuoteturvallisuuden näyttö, kuten turvallisen kehityksen elinkaaren kuvaus, penetraatiotestin yhteenveto, SBOM tai lausuma komponenttiläpinäkyvyydestä sekä tietoturvapäivitysten tukijakso.
7. Vahvistakaa MFA, vähimmän oikeuden periaate, lokitus, hallinnollisen pääsyn valvonta sekä asiakkaan auditointi- tai näyttöpyyntöoikeudet.
8. Kuvatkaa tietojen vienti, poistaminen, palautus, sopimuksen päättämisen tuki ja siirtymäapu.
9. Luetelkaa olennaiset alihankkijat ja palvelua tukevat ICT-riippuvuudet.
10. Vahvistakaa, käytetäänkö asiakastietoja koulutukseen, analytiikkaan, tuoteparannuksiin tai tekoälymallien kehittämiseen, ja yksilöikää oikeusperuste tai henkilötietojen käsittelijän ohjeisiin perustuva malli.

Pisteytä toimittaja ennen neuvottelua.

Päivitä lopuksi riskirekisteri ja soveltuvuuslausunto. Riskien käsittelyä koskevan tallenteen on osoitettava, miksi ISO/IEC 27002:2022 -hallintakeinoja 5.19, 5.20 ja 5.21 sovelletaan, mitkä sopimukselliset ja tekniset vaatimukset valittiin, kuka omistaa jäännösriskin ja mikä seurantatiheys soveltuu. Jos liiketoiminta haluaa edetä puutteista huolimatta, käytä muodollista riskin hyväksymistallennetta, jossa on päättymispäivä, korvaavat hallintakeinot ja ylimmän johdon hyväksyntä.

Sopimuslausekkeet, jotka muuttavat sääntelyn täytäntöönpantaviksi velvoitteiksi

Tietoturvaodotuksista on tehtävä sopimuksellisia sitoumuksia. Sertifikaatti voi olla hyödyllinen, mutta se vastaa harvoin kaikkiin kysymyksiin juuri teidän palvelustanne, tietojen sijainnista, alihankkijoista, tukimallista, poikkeamasitoumuksista tai irtautumisoikeuksista.

Tämä taulukko on käytännön silta oikeudellisten velvoitteiden ja hankintatyön välillä. Se auttaa myös lakiasioita, tietoturvaa ja hankintaa neuvottelemaan samasta hallintakeinoperustasta.

Ristiinvaatimustenmukaisuuden kartoitus: yksi toimittajatiedosto, monta velvoitetta

ISO/IEC 27001:2022 -standardin käyttäminen runkona tarjoaa sen edun, että yksi toimittajavarmennuksen tiedosto voi tukea useita sääntelykeskusteluja.

NIST CSF 2.0 on hyödyllinen viestintäkerros. Sen GOVERN-toiminto korostaa oikeudellista, sääntelyyn liittyvää, sopimuksellista, tietosuojaan liittyvää ja riippuvuustietoisuutta. Sen GV.SC-toimitusketjutulokset edellyttävät toimitusketjun riskienhallintaprosesseja, toimittajarooleja, toimittajien priorisointia kriittisyyden mukaan, sopimusvaatimuksia, due diligence -arviointia, seurantaa, poikkeamasuunnittelua ja päättämissuunnittelua.

Tämä yhdistyy selkeästi Zenith Blueprintin vaiheeseen 23 ja ISO/IEC 27002:2022 -hallintakeinoihin 5.19–5.21 sellaisina kuin ne on kartoitettu Zenith Controls -ratkaisussa. Se antaa hallituksille myös kielen, jonka ne ymmärtävät: nykytila, tavoitetila, puute, riski, toimenpide, omistaja ja päivämäärä.

Mitä auditoijat kysyvät

Vahvan secure-by-demand-hankintaprosessin tulisi kestää erilaiset auditointinäkökulmat.

ISO/IEC 27001:2022 -auditoija aloittaa ISMS:n toimintaympäristöstä ja soveltamisalasta. Hän kysyy, sisältyvätkö toimittajarajapinnat ja riippuvuudet soveltamisalaan, sisältävätkö sidosryhmävaatimukset NIS2:n, DORA:n, GDPR:n ja asiakassopimukset ja arvioidaanko toimittajariskejä johdonmukaisesti riskienhallintamenetelmän mukaisesti. Hän seuraa jälkeä riskien käsittelyyn, soveltuvuuslausuntoon, toimittajahallintakeinoihin, operatiiviseen näyttöön, sisäiseen auditointiin ja johdon katselmointiin.

DORA-katselmoija keskittyy ICT-tuettuihin liiketoimintatoimintoihin, kriittisiin tai tärkeisiin toimintoihin, kolmannen osapuolen riippuvuustallenteisiin, sopimuslausekkeisiin, auditointi- ja pääsyoikeuksiin, poikkeamayhteistyöhön, häiriönsietokyvyn testaukseen, irtautumisstrategioihin ja keskittymäriskiin. Jos SaaS tukee kriittistä tai tärkeää toimintoa, kevyt toimittajakysely ei riitä.

NIS2-viranomainen kysyy, miten organisaatio arvioi toimittajien kyberturvallisuuskäytäntöjä, suorien toimittajien haavoittuvuuksia, poikkeamailmoitusten tukea, jatkuvuusriippuvuuksia ja turvallisia hankintapäätöksiä. Hän testaa, tukeeko toimittajien varmentaminen organisaation omia Article 21- ja Article 23 -velvoitteita.

GDPR-katselmoija kysyy, ymmärrettiinkö rekisterinpitäjän ja henkilötietojen käsittelijän roolit ennen käsittelyn aloittamista, sovittiinko DPA:sta tai vastaavista ehdoista ennen tietojen jakamista, ilmoitettiinko alikäsittelijät, olivatko turvatoimet asianmukaisia, onko henkilötietojen tietoturvaloukkausyhteistyö sopimuksellista ja onko tietojen palautus tai poistaminen täytäntöönpantavissa.

COBIT 2019- tai ISACA-tyyppinen auditoija keskittyy hallinnointiin ja osoitusvelvollisuuteen: kuka hyväksyi toimittajan, mikä riski hyväksyttiin, noudatettiinko politiikkavaatimuksia, seurataanko poikkeuksia ja olivatko hyödyt, riskit ja resurssit tasapainossa.

Näyttöpaketin tulisi sisältää toimittajaluokittelu, liiketoimintavastaavan hyväksyntä, riskien arviointi, tarjouspyynnön tietoturvavaatimukset, toimittajan vastaukset, DPA, tietoturvaliite, SLA, auditointioikeudet, alikäsittelijärekisteri, haavoittuvuussitoumukset, poikkeamalausekkeet, pilvisijaintinäyttö, lokitus- ja salausnäyttö, irtautumisehdot, uudelleenarviointitallenteet, poikkeukset ja soveltuvuuslausunnon kartoitus.

Yleiset epäonnistumismallit ohjelmistohankinnoissa

Ensimmäinen epäonnistuminen on hankinnan käsitteleminen kaupallisena työnkulkuna ja tietoturvan käsitteleminen teknisenä työnkulkuna. Siihen mennessä, kun tietoturva saa sopimuksen, liiketoiminta on jo sitoutunut psykologisesti, käyttöönoton päivämäärä on ilmoitettu ja neuvotteluvoima on heikko.

Toinen epäonnistuminen on näytön korvaaminen. Toimittaja toimittaa sertifikaatin, ja ostaja olettaa sen vastaavan kaikkiin kysymyksiin. Sertifiointi voi auttaa, mutta se ei välttämättä kata juuri kyseistä tuotetta, palvelinaluetta, tukimallia, alihankkijaketjua, poikkeamavelvoitteita, tekoälyyn liittyvää datan käyttöä tai irtautumisvaatimuksia.

Kolmas epäonnistuminen on alaspäin suuntautuvan riskin huomiotta jättäminen. SaaS-toimittaja voi tukeutua pilvi-infrastruktuuriin, analytiikkatyökaluihin, tukialustoihin, offshore-kehitystiimeihin, tekoälymallien tarjoajiin ja maksupalveluntarjoajiin. ISO/IEC 27002:2022 -hallintakeino 5.21 edellyttää huomiota suoran toimittajan taustalla olevaan ICT-toimitusketjuun. DORA:ssa tämä liittyy alihankintaan ja keskittymäriskiin. GDPR:ssä se liittyy alikäsittelijöihin. NIS2:ssa se liittyy suorien toimittajien haavoittuvuuksiin ja toimittajien kyberturvallisuuskäytäntöihin.

Neljäs epäonnistuminen on heikko poikkeamakieli. Sopimus, jossa todetaan “toimittaja ilmoittaa asiakkaalle viipymättä”, ei välttämättä tue NIS2:n ennakkovaroitusta, DORA:n vaiheistettua raportointia, asiakasviestintää tai sisäistä eskalointia. Poikkeamalausekkeet tarvitsevat aikarajat, laukaisuehdot, yhteyshenkilöt, yhteistyövelvoitteet ja näyttövelvoitteet.

Viides epäonnistuminen on epäselvät irtautumisoikeudet. Jos toimittajasta tulee turvaton, vaatimustenvastainen, yrityskaupan kohde, maksukyvytön tai strategisesti sopimaton, ostaja tarvitsee viennin, poistamisen, siirtymätuen, tilien käytöstäpoiston ja hävitysnäytön. Irtautuminen ei ole juridinen jälkiajatus. Se on häiriönsietokyvyn hallintakeino.

Hankintaportista eläväksi toimittajien varmentamiseksi

Secure-by-demand-hankinta ei pääty allekirjoitukseen. Kypsässä Clarysec-tyyppisessä toimittajaelinkaaressa on viisi vaihetta.

Korkean riskin toimittajilla seurannan on syytä sisältää näytön päivittäminen, tietoturvakatselmointikokoukset, osallistuminen poikkeamaharjoituksiin, käyttöoikeuskatselmointi, haavoittuvuus- ja korjausraportointi, palvelumuutosten katselmointi ja alikäsittelijäpäivitykset. Alemman riskin toimittajilla vuosittainen katselmointi voi riittää. ISO 27001:n skaalautuvuus, NIS2:n suhteellisuus ja DORA:n suhteellisuus tukevat räätälöintiä, mutta räätälöinti on perusteltava ja dokumentoitava.

Clarysecin seuraava askel

Seuraava riskialtis SaaS-hankinta ei odota täydellistä hallinnointiuudistusta. Aloita seuraavasta hankintapyynnöstä.

Käytä Zenith Blueprint: auditoijan 30 vaiheen tiekarttaa vaiheen 23 toimittajasuhdehallintakeinojen ja vaiheen 21 ulkoistetun kehittämisen hallintakeinojen toteuttamiseen. Käytä Zenith Controls -ratkaisua ISO/IEC 27002:2022 -hallintakeinojen 5.19, 5.20 ja 5.21 kartoittamiseen NIS2-, DORA-, GDPR-, NIST CSF 2.0 - ja COBIT-suuntautuneisiin auditointiodotuksiin. Käytä Clarysecin politiikkakirjastoa, mukaan lukien Kolmansien osapuolten ja toimittajien tietoturvapolitiikka, Sovellusturvallisuusvaatimusten politiikka, Pilvipalvelujen käyttöpolitiikka ja Lain- ja sääntelyvaatimusten noudattamisen politiikka, jotta portista tulee täytäntöönpantava.

Ennen seuraavan sopimuksen allekirjoittamista edellytä toimittajaluokittelua, tietoturvanäyttöä, DPA-valmiutta, poikkeamasitoumuksia, haavoittuvuuksien käsittelyä, alihankkijaläpinäkyvyyttä, auditointioikeuksia ja irtautumisehtoja.

Tätä on secure-by-demand-hankinta. Näin tietoturvajohtajat muuttavat sääntelypaineen hankintavoimaksi. Näin vaatimustenmukaisuuspäälliköt muuttavat päällekkäiset velvoitteet yhdeksi näyttötiedostoksi. Näin auditoijat näkevät, että toimittajariski huomioitiin ennen riippuvuuden muodostumista. Ja näin liiketoimintavastaavat ostavat ohjelmistoja nopeammin perimättä hallitsematonta riskiä.

Haluatko muuttaa seuraavan ohjelmistohankintasi auditointivalmiiksi hallintakeinoksi? Tutustu Clarysecin integroituun politiikkakokonaisuuteen, lataa Zenith Blueprint, tarkastele Zenith Controls -ratkaisua tai varaa demo rakentaaksesi secure-by-demand-hankintaohjelman, joka kestää NIS2-, DORA-, GDPR- ja CRA-odotukset sekä todellisen auditoijan tarkastelun.