Kyselylomaketta pidemmälle: tietoturvajohtajan käytännön opas korkean riskin toimittajien auditointiin NIS2- ja DORA-vaatimuksia varten

Raportti laskeutui tietoturvajohtaja Maria Valenin työpöydälle hiljaisella tömähdyksellä, joka tuntui enemmän hälytykseltä kuin paperin ääneltä. Kyseessä oli tulevaa DORA-vaatimustenmukaisuuskatselmointia varten laadittu ennakkoarviointi, ja yksi rivi oli korostettu kirkkaan punaisella: ”Riittämätön varmuus kriittisestä kolmannen osapuolen palveluntarjoajasta, CloudSphere.”

CloudSphere ei ollut mikä tahansa toimittaja. Se oli yhtiön uuden digitaalisen pankkialustan selkäranka ja käsitteli päivittäin miljoonia transaktioita. Marialla oli toimittajan ISO/IEC 27001:2022 -sertifikaatti arkistossa. Hänellä oli myös toimittajan täyttämä tietoturvakysely, laaja 200 kysymyksen asiakirja. Ennakkotarkastajat kuitenkin viestivät, että korkean riskin ja kriittisen toimittajan kohdalla rastiruutuihin perustuva vaatimustenmukaisuus ei enää riitä. Pelisäännöt olivat muuttuneet.

Kun sekä NIS2-direktiivi että digitaalista häiriönsietokykyä koskeva DORA-asetus ovat täysimääräisesti voimassa, sääntelyviranomaiset katsovat paperijälkeä pidemmälle. Ne edellyttävät konkreettista näyttöä toimittajien huolellisuusarvioinnista, jatkuvasta seurannasta ja koko toimitusketjun vahvasta hallinnasta. Marian haaste on tuttu tietoturvajohtajille kaikkialla: miten kyselylomakkeesta siirrytään aidosti auditoimaan ja suojaamaan kaikkein kriittisimpiä toimittajia? Se edellyttää strategista muutosta passiivisesta validoinnista aktiiviseen, näyttöön perustuvaan varmennukseen.

Staattisen kyselylomakkeen puutteet dynaamisessa toimintaympäristössä

Tietoturvakysely on ollut vuosien ajan kolmansien osapuolten riskienhallinnan kulmakivi. Se on kuitenkin staattinen tilannekuva dynaamisessa uhkaympäristössä. Toimittajan riskiprofiili ei ole pysyvä; se muuttuu jokaisen uuden uhan, järjestelmämuutoksen tai käyttöönotetun alihankkijan myötä. Pelkkään itsearviointiin tukeutuminen CloudSpheren kaltaisen kriittisen toimittajan kohdalla on kuin ohjaisi myrskyssä viime vuoden sääkartan perusteella.

NIS2-direktiivi edellyttää nimenomaisesti riskiperusteista lähestymistapaa ja vaatii, että tietoturvatoimenpiteet suhteutetaan todellisiin riskeihin. Tämä tarkoittaa, että yksi kaikille sopiva kyselylomake ei vastaa nykyisiä sääntelyodotuksia. Ajat, jolloin sertifikaatti tai täytetty tarkistuslista saattoi korvata todentavan aineiston, ovat ohi. Todellinen riski sijaitsee paperijäljen ulkopuolella.

Tässä rakenteinen, elinkaareen perustuva lähestymistapa on välttämätön. Kyse ei ole kyselylomakkeiden hylkäämisestä, vaan niiden täydentämisestä syvemmällä ja tarvittaessa perusteellisemmalla varmennuksella niiden toimittajien osalta, joilla on aidosti merkitystä. Tämä on Clarysecin Kolmansien osapuolten ja toimittajien tietoturvapolitiikan keskeinen periaate. Yksi sen perustavoitteista on:

“Edellyttää muodollista toimittajien huolellisuusarviointia ja dokumentoituja riskien arviointeja ennen uusien toimittajien käyttöönottoa tai korkean riskin palvelusopimusten uusimista.”

• Kohdasta ”Tavoitteet”, politiikan lauseke 3.3

Tämä lauseke muuttaa ajattelutavan yksinkertaisesta tarkistuksesta muodolliseksi selvitykseksi. Se on ratkaiseva ensimmäinen askel sellaisen ohjelman rakentamisessa, joka kestää sääntelytarkastelun.

Toimittajariski NIS2:n ja DORA:n näkökulmasta: uudet odotukset

Sekä NIS2 että DORA edellyttävät, että organisaatiot tunnistavat, arvioivat ja seuraavat järjestelmällisesti riskejä koko toimittajakentässään. Ne muuttavat toimittajahallinnan hankintatoiminnon tehtävästä operatiivisen häiriönsietokyvyn ja tietoturvallisuuden keskeiseksi pilariksi.

Uusi sääntely-ympäristö edellyttää selkeitä viitekehyksiä, jotka on kytketty tiiviisti vakiintuneisiin standardeihin, kuten ISO/IEC 27001:2022. Alla on ylätason yhteenveto siitä, mitä nämä viitekehykset odottavat toimittajahallinnan ohjelmalta:

Vahvaa toimittaja-auditointiohjelmaa ei tarvitse rakentaa tyhjästä. ISO/IEC 27001:2022 -viitekehys ja erityisesti sen liite A tarjoavat tehokkaan mallin. Clarysecissä ohjaamme asiakkaita rakentamaan ohjelmansa kolmen toisiinsa liittyvän hallintakeinon ympärille. Yhdessä ne muodostavat kattavan toimittajahallinnan elinkaaren.

Puolustettavissa olevan auditointiviitekehyksen rakentaminen: ISO 27001:2022 -elinkaari

Sääntelyviranomaisten odotukset täyttävän ohjelman rakentaminen edellyttää rakenteista lähestymistapaa, joka perustuu maailmanlaajuisesti tunnustettuun standardiin. ISO/IEC 27001:2022 -standardin toimittajaturvallisuuden hallintakeinot tarjoavat elinkaaren kolmansien osapuolten riskien hallintaan toimittajasuhteen alusta sen päättämiseen. Tarkastellaan, miten Maria voi käyttää tätä elinkaarta puolustettavissa olevan auditointisuunnitelman rakentamiseen CloudSphereä varten.

Vaihe 1: Perusta – tietoturvallisuus toimittajasuhteissa (5.19)

Hallintakeino 5.19 on strateginen lähtökohta. Se edellyttää muodollisten prosessien perustamista koko toimittajaekosysteemiin liittyvien tietoturvariskien tunnistamiseen, arviointiin ja hallintaan. Tässä määritellään, mitä ”korkea riski” organisaatiossa tarkoittaa, ja asetetaan yhteiset säännöt.

Clarysecin Zenith Controls: The Cross-Compliance Guide tarjoaa yksityiskohtaisen erittelyn kohdasta 5.19 ja havainnollistaa sen roolia toimittajahallinnan keskuspisteenä. Tämä hallintakeino liittyy olennaisesti muihin hallintakeinoihin, kuten 5.21 (Tietoturvallisuus ICT-toimitusketjussa), joka kattaa laitteisto- ja ohjelmistokomponentit, sekä 5.14 (Tietojen siirto), joka ohjaa tietojen turvallista vaihtoa. Toimittajasuhdetta ei voi hallita tehokkaasti, ellei samalla hallita toimittajan tuottamaa teknologiaa ja organisaation jakamia tietoja.

Marialle tämä tarkoittaa, että CloudSpheren auditoinnin on mentävä toimittajan yritystason tietoturvatilannetta pidemmälle ja pureuduttava toimittajan tarjoaman varsinaisen alustan turvallisuuteen. Zenith Controls -opas korostaa, että 5.19:n vahva toteutus tukee suoraan merkittävien säädösten noudattamista:

• NIS2 (Article 21(2)(d)): Velvoittaa organisaatiot hallitsemaan toimitusketjuriskiä keskeisenä osana tietoturvaviitekehystään.
• DORA (Articles 28–30): Edellyttää vahvaa ICT-kolmansien osapuolten riskienhallinnan viitekehystä, mukaan lukien kriittisyysluokittelu ja sopimusta edeltävä toimittajan huolellisuusarviointi.
• GDPR (Article 28): Edellyttää, että rekisterinpitäjät käyttävät vain sellaisia käsittelijöitä, jotka antavat riittävät takeet tietosuojasta.

Tämä hallintakeino edellyttää toimittajariskien luokittelua, jatkuvaa seurantaa ja käyttöoikeuksien oikea-aikaista perumista. Sen tarkoituksena on varmistaa, että tietoturva on sisäänrakennettu toimittajan elinkaareen eikä lisätty jälkikäteen.

Vaihe 2: Soveltaminen – tietoturvallisuuden huomioiminen toimittajasopimuksissa (5.20)

Tietoturvavaatimus, jota ei ole kirjattu sopimukseen, on käytännössä vain suositus. Hallintakeino 5.20 on kohta, jossa hallinta muuttuu sopimusperusteisesti velvoittavaksi. Korkean riskin toimittajan kohdalla sopimus on tehokkain auditointiväline.

Kuten Zenith Controls korostaa, sopimusten on oltava yksiselitteisiä. Epämääräiset lupaukset ”alan parhaasta tietoturvasta” eivät riitä. CloudSpheren kaltaisen toimittajan osalta Marian on varmistettava, että sopimus sisältää täsmälliset ja mitattavat lausekkeet, jotka antavat hänen organisaatiolleen konkreettisen valvontamahdollisuuden:

• Tarkastusoikeudet: Lauseke, joka antaa organisaatiolle nimenomaisen oikeuden tehdä teknisiä arviointeja, katselmoida todentavaa aineistoa tai käyttää kolmatta osapuolta auditoinnin suorittamiseen organisaation puolesta.
• Tietoturvaloukkauksista ilmoittamisen määräajat: Täsmälliset ja tiukat määräajat, esimerkiksi 24 tunnin kuluessa havaitsemisesta, tietoturvapoikkeamasta ilmoittamiselle, ei vain epämääräistä velvoitetta ilmoittaa ”ilman aiheetonta viivytystä”.
• Alihankkijoiden eli neljänsien osapuolten hallinta: Lauseke, joka edellyttää, että toimittaja soveltaa samoja tietoturvastandardeja omiin kriittisiin alihankkijoihinsa ja ilmoittaa muutoksista. Tämä on ratkaisevaa alihankintaketjun riskien hallinnassa.
• Turvallinen irtautumisstrategia: Selkeät velvoitteet tietojen palauttamisesta tai sertifioidusta hävittämisestä sopimuksen päättyessä.

DORA on tässä erityisen yksityiskohtainen. Article 30 luettelee pakolliset sopimusmääräykset, mukaan lukien esteetön pääsy auditoijille ja viranomaisille, tarkat tiedot palvelujen sijainneista sekä kattavat irtautumisstrategiat. Auditoijat poimivat korkean riskin toimittajasopimuksia otoksena ja tarkistavat nämä lausekkeet suoraan.

Vaihe 3: Jatkuva silmukka – toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta (5.22)

Elinkaaren viimeinen osa on hallintakeino 5.22, joka muuttaa toimittajien valvonnan pistemäisestä tarkistuksesta jatkuvaksi prosessiksi. Auditoinnin ei tulisi olla yllätyksellinen tapahtuma, vaan validointipiste jatkuvassa ja läpinäkyvässä toimittajasuhteessa.

Tässä moni organisaatio epäonnistuu. Sopimus allekirjoitetaan ja arkistoidaan. Korkean riskin toimittajien kohdalla varsinainen työ alkaa kuitenkin perehdytyksen jälkeen. Zenith Controls -opas yhdistää 5.22:n kriittisiin operatiivisiin prosesseihin, kuten 8.8 (Teknisten haavoittuvuuksien hallinta) ja 5.29 (Tietoturvallisuus häiriötilanteissa). Tämä tarkoittaa, että tehokas seuranta on paljon enemmän kuin vuosittainen katselmointikokous. Se sisältää muun muassa:

• Kolmansien osapuolten todentavan aineiston katselmointi: SOC 2 Type II -raporttien, ISO 27001 -valvonta-auditointien tulosten tai penetraatiotestausten yhteenvetojen aktiivinen hankkiminen ja analysointi. Olennaista on katselmoida poikkeukset ja seurata niiden korjaavia toimenpiteitä.
• Poikkeamien seuranta: Julkisesti ilmoitettujen toimittajaan liittyvien tietomurtojen tai tietoturvapoikkeamien seuraaminen ja niiden mahdollisen vaikutuksen muodollinen arviointi omaan organisaatioon.
• Muutosten hallinta: Prosessi, jossa toimittajan palvelun merkittävä muutos, kuten uusi datakeskussijainti tai uusi kriittinen alihankkija, käynnistää automaattisesti riskin uudelleenarvioinnin.

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap tarjoaa tähän käytännön ohjeistusta, erityisesti vaiheessa 24, joka käsittelee alihankkijariskiä. Se ohjeistaa:

“Tunnista jokaisen kriittisen toimittajan osalta, käyttääkö se alihankkijoita tai alikäsittelijöitä, joilla voi olla pääsy tietoihisi tai järjestelmiisi. Dokumentoi, miten tietoturvavaatimuksesi välitetään näille osapuolille… Pyydä mahdollisuuksien mukaan luettelo keskeisistä alihankkijoista ja varmista, että tarkastusoikeutesi tai oikeutesi saada todentavaa aineistoa koskee myös niitä.”

Tämä on Marialle ratkaiseva huomio. Käyttääkö CloudSphere kolmannen osapuolen data-analytiikkayritystä? Onko sen infrastruktuuri sijoitettu merkittävään julkiseen pilvipalveluun? Nämä alihankintaketjun riippuvuudet muodostavat merkittävän ja usein näkymättömän riskin, joka auditoinnin on tuotava esiin.

Teoriasta käytäntöön: Marian käytännön auditointisuunnitelma CloudSphereä varten

Tämän ISO 27001:2022 -elinkaaren pohjalta Marian tiimi laatii CloudSphereä varten uuden auditointisuunnitelman, joka menee selvästi kyselylomaketta pidemmälle ja osoittaa sääntelyviranomaisten edellyttämää kypsää, riskiperusteista hallintaa.

1. Sopimuskatselmointi: Tiimi aloittaa kartoittamalla nykyisen CloudSphere-sopimuksen DORA Article 30 -vaatimuksiin ja hallintakeinon 5.20 parhaisiin käytäntöihin. He laativat puuteanalyysiraportin seuraavan uusimiskierroksen tueksi ja nykyisen auditoinnin painopisteiden priorisoimiseksi.

2. Kohdennettu todentavan aineiston pyyntö: Yleisen kyselylomakkeen sijasta he lähettävät muodollisen pyynnön täsmällisestä todentavasta aineistosta, mukaan lukien:

   • Uusin SOC 2 Type II -raportti sekä yhteenveto siitä, miten kaikki havaitut poikkeukset on korjattu.
   • Johdon yhteenveto viimeisimmästä ulkoisesta penetraatiotestistä.
   • Täydellinen luettelo kaikista alihankkijoista eli neljänsistä osapuolista, jotka käsittelevät organisaation tietoja tai joilla on niihin pääsy.
   • Näyttö siitä, että tietoturvavaatimukset on sopimusperusteisesti välitetty kyseisille alihankkijoille.
   • Lokit tai raportit, jotka osoittavat kriittisten haavoittuvuuksien, kuten Log4j:n ja MOVEit:n, oikea-aikaisen paikkauksen viimeisten kuuden kuukauden aikana.

3. Tekninen validointi: He vetoavat tarkastusoikeutta koskevaan lausekkeeseen ja sopivat CloudSpheren tietoturvatiimin kanssa teknisestä syväkatselmuksesta. Asialista keskittyy toimittajan tietoturvapoikkeamiin reagoinnin pelikirjoihin, Cloud Security Posture Management (CSPM) -työkaluihin ja tietovuotojen estämiseen tarkoitettuihin kontrolleihin.

4. Muodollinen poikkeustenhallinta: Jos CloudSphere vastustaa tietyn todentavan aineiston toimittamista, Maria on valmistautunut. Hänen organisaationsa hallintaprosessi, joka on määritelty Kolmansien osapuolten ja toimittajien tietoturvapolitiikassa, on selkeä:

“Korkean riskin poikkeukset, esimerkiksi sääntelyn alaisia tietoja käsittelevät tai kriittisiä järjestelmiä tukevat toimittajat, on hyväksytettävä tietoturvajohtajalla, laki- ja vaatimustenmukaisuustoiminnolla sekä hankintajohdolla ja kirjattava ISMS-poikkeusrekisteriin.”

• Kohdasta ”Riskienkäsittely ja poikkeukset”, politiikan lauseke 7.3

Näin varmistetaan, että todentavan aineiston toimittamisesta kieltäytymistä ei vain sivuuteta, vaan riski hyväksytään muodollisesti organisaation ylimmillä tasoilla. Tämä on prosessi, jota auditoijat arvostavat.

Auditoijan näkökulma: mitä eri auditoijat edellyttävät

Todella häiriönsietokykyisen ohjelman rakentaminen edellyttää ajattelua auditoijan tavoin. Eri auditointiviitekehykset tarkastelevat asioita eri näkökulmista, ja niiden kysymysten ennakointi on onnistumisen kannalta keskeistä. Alla on koottu näkymä siitä, mitä eri auditoijat edellyttäisivät toimittajahallinnan ohjelmaa arvioidessaan:

Tämä moninäkökulmainen tarkastelu osoittaa, että vahvan ohjelman tarkoituksena ei ole täyttää yhtä standardia, vaan rakentaa kokonaisvaltainen hallintaviitekehys, joka tuottaa kaikkien niiden edellyttämän todentavan aineiston.

Kriittiset sudenkuopat: missä toimittaja-auditoinnit epäonnistuvat

Monet toimittajien valvontaohjelmat jäävät vajaiksi yleisten ja vältettävissä olevien virheiden vuoksi. Kiinnitä erityistä huomiota seuraaviin kriittisiin sudenkuoppiin:

• Auditointi tapahtumana: Tukeutuminen kertaluonteisiin auditointeihin toimittajan käyttöönoton tai sopimuksen uusimisen yhteydessä sen sijaan, että toteutetaan jatkuva seuranta.
• Sertifiointiin tuudittautuminen: ISO- tai SOC 2 -sertifikaatin hyväksyminen sellaisenaan ilman raportin yksityiskohtien, soveltamisalan ja poikkeusten katselmointia.
• Epämääräiset sopimukset: Nimenomaisten ja velvoittavien lausekkeiden puuttuminen auditointioikeuksista, tietoturvaloukkauksista ilmoittamisesta ja tietojen käsittelystä.
• Heikko omaisuus- ja toimittajaluettelon hallinta: Kyvyttömyys tuottaa kattavaa, riskitasoihin jaettua luetteloa kaikista toimittajista ja tiedoista, joihin niillä on pääsy.
• Alihankintaketjun riskin sivuuttaminen: Toimittajan omien kriittisten alihankkijoiden aiheuttamien riskien tunnistamatta ja hallitsematta jättäminen eli neljännen osapuolen riskin sivuuttaminen.
• Varmistamaton haavoittuvuuksien hallinta: Luottaminen siihen, että toimittaja paikkaa kriittiset haavoittuvuudet, ilman todentavan aineiston pyytämistä.

Käytännön tarkistuslista korkean riskin toimittaja-auditointeihin

Käytä tätä Zenith Blueprint -oppaasta mukautettua tarkistuslistaa varmistaaksesi, että jokaisen korkean riskin toimittajan auditointiprosessi on perusteellinen ja puolustettavissa.

Päätelmä: häiriönsietokykyisen ja puolustettavissa olevan toimitusketjun rakentaminen

Kriittisten toimittajien rastiruutuihin perustuvan vaatimustenmukaisuuden aika on ohi. NIS2:n ja DORA:n kaltaisten säädösten tiukka valvonta edellyttää perustavanlaatuista siirtymää kohti jatkuvaa, näyttöön perustuvaa varmennusta. Marian kaltaisten tietoturvajohtajien on johdettava organisaationsa staattista kyselylomaketta pidemmälle.

Kun ohjelma rakennetaan ISO/IEC 27001:2022 -hallintakeinojen hyväksi todetun elinkaaren varaan, syntyy viitekehys, joka ei ainoastaan täytä vaatimuksia vaan myös vähentää riskiä aidosti. Tämä edellyttää, että toimittajaturvallisuutta käsitellään strategisena osa-alueena, sopimuksiin sisällytetään velvoittavat vaatimukset ja toimittajasuhdetta valvotaan tarkasti koko sen ajan.

Organisaation turvallisuus on yhtä vahva kuin sen heikoin lenkki, ja tämän päivän verkottuneessa ekosysteemissä tuo lenkki on usein kolmas osapuoli. On aika ottaa hallinta takaisin.

Valmis siirtymään kyselylomaketta pidemmälle?

Clarysecin integroidut työkalupaketit tarjoavat perustan maailmanluokan toimittajariskien hallintaohjelman rakentamiseen. Ohjelman tulee kestää mikä tahansa auditointi.

• Lataa politiikkamallimme: Toteuta vahva hallintaviitekehys yritystason Kolmansien osapuolten ja toimittajien tietoturvapolitiikalla sekä sen pk-yrityksille tarkoitetulla vastineella.
• Seuraa Zenith Blueprint -opasta: Käytä Zenith Blueprint: An Auditor’s 30-Step Roadmap -opastamme vaatimustenmukaisen ISMS:n toteuttamiseen ja auditointiin. Se sisältää erilliset vaiheet toimittajariskin hallintaan.
• Hyödynnä Zenith Controls -opasta: Pyydä demo Zenith Controls: The Cross-Compliance Guide -oppaastamme ja kartoita toimittajakontrollit NIS2-, DORA-, GDPR-, NIST- ja muihin vaatimuksiin. Näin varmistat, että auditointisuunnitelmasi on kattava ja puolustettavissa.