NIS2:n mukaiset toimittajasopimukset ISO 27001 -näytöllä

On maanantai kello 07.40. Pilvipalveluja hyödyntävän logistiikka-alustan tietoturvajohtaja avaa sähköpostin hallinnoidun valvonta- ja reagointipalvelun toimittajalta. Viesti on lyhyt, varovainen ja epämiellyttävä: toimittaja on havainnut epäilyttävää pääsyä tukiympäristöön, jota useat asiakkaat käyttävät. Yksityiskohtia on vähän. Toimittaja lupaa päivityksen ”niin pian kuin käytännössä mahdollista”.

Kello 08.15 vaatimustenmukaisuuspäällikkö kysyy, voiko tämä käynnistää NIS2-raportoinnin. Kello 08.40 hankinta etsii sopimusta. Kello 09.10 hallituksen sihteeri pyytää tilannekatsausta johdon vastuun osoittamiseksi. Kello 10.00 lakiasiat kysyy, sisältääkö sopimus 24 tunnin ilmoitusvelvoitteen, auditointioikeudet, alihankkijoiden kontrollit, pääsyn todentavaan näyttöön, liiketoiminnan jatkuvuusvelvoitteet sekä tietojen palauttamista ja poistamista koskevat määräykset.

Kukaan ei halua huomata käynnissä olevan poikkeaman aikana, että kriittisen toimittajan sopimuksessa lukee vain ”kohtuulliset tietoturvatoimenpiteet”.

Tässä kohdassa NIS2:n mukaisten toimittajasopimusten lausekkeet lakkaavat olemasta juridista vakiosisältöä ja muuttuvat operatiivisiksi kontrolleiksi. Keskeisille ja tärkeille toimijoille toimittajahallinta on nyt osa hallituksen vastuuta, valvontaviranomaisille esitettävää näyttöä, valmiutta poikkeamatilanteisiin, asiakasvarmennusta, tietosuojan vaatimustenmukaisuutta ja häiriönsietokyvyn suunnittelua. Allekirjoitettu sopimus ei riitä. Organisaation on pystyttävä osoittamaan, että toimittajariskit tunnistetaan, hyväksytään, käsitellään ja niitä seurataan sekä että niistä on todentava näyttö.

Clarysecin lähestymistapa alkaa yksinkertaisesta periaatteesta: jos toimittajalauseketta ei voida seurata, todentaa ja testata, se ei ole kontrolli.

Zenith Blueprint: auditoijan 30 vaiheen tiekartta sijoittaa toimittajasuhteet Kontrollit käytännössä -vaiheeseen, vaiheeseen 23, jossa sopimukset, seuranta, käyttöönotto, uudelleenarviointi ja auditointinäyttö muutetaan käytännön ISMS-työksi. Zenith Controls: vaatimustenmukaisuuden vastaavuusopas puolestaan yhdistää ISO/IEC 27002:2022 -standardin toimittajakontrollit NIS2-, DORA-, GDPR-, NIST- ja COBIT 2019 -vaatimuksiin, tukeviin ISO-standardeihin ja auditointimenetelmiin.

Tuloksena on toimittajahallinnan malli, jota hankinta, lakiasiat, tietoturva, tietosuoja ja hallitus voivat kaikki käyttää.

Miksi NIS2 muuttaa toimittajasopimukset todentavaksi näytöksi

NIS2 Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden hallintoelimet hyväksyvät kyberturvallisuusriskien hallintatoimenpiteet, valvovat niiden toteutusta ja vastaavat rikkomuksista. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, kuten riskianalyysiä, poikkeamien käsittelyä, liiketoiminnan jatkuvuutta, toimitusketjun tietoturvaa, turvallista hankintaa ja ylläpitoa, vaikuttavuuden arviointia, kyberhygieniaa, kryptografiaa, henkilöstöturvallisuutta, pääsynhallintaa, omaisuudenhallintaa ja MFA:ta silloin, kun se on tarkoituksenmukaista.

Article 21(3) tekee toimittajahuolellisuusarvioinnista nimenomaisen vaatimuksen. Organisaatioiden on otettava huomioon suorien toimittajien ja palveluntarjoajien erityiset haavoittuvuudet, tuotteiden ja kyberturvallisuuskäytäntöjen yleinen laatu sekä turvallisen kehittämisen menettelyt.

Tämä sääntelykieli luo käytännön velvoitteen: toimittajasuhteiden on oltava riskiperusteisia, sopimuksellisesti täytäntöönpantavia ja katselmoitavissa. Kansioon tallennettu toimittajakysely ei riitä. Yleinen sopimus ilman poikkeamien aikataulua, näyttöoikeuksia ja näkyvyyttä alihankkijoihin ei riitä. Toimittajasertifikaatti, jota kukaan ei ole katselmoinut, ei riitä.

ISO/IEC 27001:2022 tarjoaa toimintamallin. Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmät, lakisääteiset ja sopimusperusteiset velvoitteet, ISMS:n soveltamisalan ja riippuvuudet. Kohdat 5.1–5.3 edellyttävät johtajuutta, politiikkaa, rooleja ja raportointia. Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä ja soveltuvuuslausuntoa. Kohdat 8.1–8.3 edellyttävät operatiivista kontrollia, riskien arviointien toistamista ja dokumentoituja tuloksia.

Toimittajahallinnan kannalta tärkeimpiä ISO/IEC 27002:2022 liite A:n kontrolleja ovat:

• A.5.19 Toimittajasuhteiden tietoturva
• A.5.20 Tietoturvan käsittely toimittajasopimuksissa
• A.5.21 Tietoturvan hallinta ICT-toimitusketjussa
• A.5.22 Toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta
• A.5.24 Poikkeamienhallinnan suunnittelu ja valmistelu
• A.5.25 Tietoturvatapahtumien arviointi ja päätöksenteko
• A.5.26 Tietoturvapoikkeamiin reagointi
• A.5.27 Tietoturvapoikkeamista oppiminen
• A.5.28 Todisteiden kerääminen
• A.5.29 Tietoturva häiriötilanteissa
• A.5.30 ICT-valmius liiketoiminnan jatkuvuutta varten
• A.5.31 Lakisääteiset, viranomais-, sääntely- ja sopimusperusteiset vaatimukset
• A.5.34 Yksityisyydensuoja ja PII:n suojaaminen
• A.8.8 Teknisten haavoittuvuuksien hallinta
• A.8.13 Varmuuskopiointi
• A.8.15 Lokitus
• A.8.16 Seurantatoiminnot
• A.8.24 Kryptografian käyttö
• A.8.32 Muutoksenhallinta

Keskeistä on omistajuus. Lausekkeella on vähän arvoa, ellei joku omista riskiä, joku katselmoi näyttöä, joku seuraa poikkeuksia ja joku eskaloi vaatimustenvastaisuudet.

Enterprise-tason Third party and supplier security policy tekee tämän nimenomaiseksi:

”Oikeus auditoida, tarkastaa ja pyytää tietoturvanäyttöä”

Kohdasta ”Hallintavaatimukset”, politiikkalauseke 5.3.4.

Pk-yrityksille tarkoitettu Third-Party and Supplier Security Policy-sme asettaa saman käytännön odotuksen:

”Auditointioikeudet tai vaatimustenmukaisuuden todentavan näytön saatavuus”

Kohdasta ”Hallintavaatimukset”, politiikkalauseke 5.3.4.

Tällä erolla on merkitystä. Pienempi organisaatio ei välttämättä voi auditoida jokaista suurta pilvipalveluntarjoajaa paikan päällä, mutta se voi edellyttää pääsyä varmennusnäyttöön, kuten ISO/IEC 27001:2022 -sertifioinnin soveltamisalaan, SOC-raportteihin, penetraatiotestien yhteenvetoihin, haavoittuvuuksien korjaamista koskeviin vakuutuksiin, poikkeamayhteenvetoihin, liiketoiminnan jatkuvuuden testiraportteihin ja tietojen poistamista koskeviin vahvistuksiin.

NIS2-toimittajavarmennuksen kolmen kontrollin selkäranka

Clarysecin vaatimustenmukaisuuden vastaavuusmallissa kolme ISO/IEC 27002:2022 -kontrollia muodostaa NIS2:n mukaisen toimittajahallinnan selkärangan: 5.19, 5.20 ja 5.22.

A.5.19 tunnistaa toimittajariskin

Kontrolli A.5.19, toimittajasuhteiden tietoturva, on perusta. Se edellyttää, että organisaatiot suojaavat tiedot ja omaisuuserät, joihin toimittajat pääsevät tai joita ne käsittelevät, säilyttävät tai hallinnoivat.

Zenith Controls luokittelee tämän ennaltaehkäiseväksi kontrolliksi, joka kattaa luottamuksellisuuden, eheyden ja saatavuuden, kyberturvallisuuden osa-alueella ”Tunnista” ja operatiivisella kyvykkyydellä ”Toimittajasuhteiden tietoturva”. Se yhdistää A.5.19:n kontrolleihin A.5.20, A.5.21, A.5.14, A.5.36 ja A.5.10. Käytännössä organisaatio tunnistaa toimittajariskin, määrittää tietoturvaodotukset, hallitsee ICT-toimitusketjun altistusta, suojaa tiedonsiirtoa, seuraa vaatimustenmukaisuutta ja ulottaa hyväksyttävän käytön velvoitteet ulkoisiin osapuoliin.

NIS2:n osalta tämä vastaa suoraan Article 21(2)(d):n toimitusketjun tietoturvaa ja Article 21(3):n toimittajahuolellisuusarviointia. GDPR:n osalta se tukee vaatimusta käyttää henkilötietojen käsittelijöitä, jotka antavat riittävät takeet. DORA:n osalta se tukee TVT-kolmansien osapuolten riskienhallintaa, sopimusta edeltävää huolellisuusarviointia, kriittisyyden arviointia, keskittymäriskiä ja elinkaaren aikaista valvontaa.

A.5.20 tekee vaatimuksesta täytäntöönpantavan

Kontrolli A.5.20, tietoturvan käsittely toimittajasopimuksissa, muuttaa tietoturvaodotukset sopimusvelvoitteiksi. Zenith Controls kuvaa A.5.19:n ja A.5.20:n välisen suhteen selkeästi:

”5.20 toimii kohdassa 5.19 tunnistettujen tietoturvatarpeiden ja riskien sopimuksellisena muotoiluna. Kun 5.19 koskee kolmansien osapuolten riskien arviointia ja tietoturvaodotusten määrittämistä, 5.20 varmistaa, että nämä odotukset ovat sopimusten tai palvelutasosopimusten (SLA) kautta oikeudellisesti sitovia. Ilman 5.20:tä kohdassa 5.19 tunnistetuilta tietoturvatoimenpiteiltä puuttuisi täytäntöönpantavuus.”

Tässä NIS2-riskipäätökset muuttuvat lausekkeiksi: tietoturvaloukkauksista ilmoittaminen, auditointi- ja näyttöoikeudet, salaus, pääsynhallinta, haavoittuvuuksien hallinta, alihankkijoiden hyväksyntä, turvallinen siirto, jatkuvuus, sääntely-yhteistyö, irtautumistuki ja tietojen poistaminen.

A.5.22 osoittaa, että sopimus elää

Kontrolli A.5.22, toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta, estää toimittajavarmennusta jäämästä kertaluonteiseksi käyttöönottotehtäväksi. Zenith Controls yhdistää A.5.22:n A.5.19:ään ja A.5.20:een, mutta myös A.5.29:n mukaiseen tietoturvaan häiriötilanteissa, A.8.8:n mukaiseen teknisten haavoittuvuuksien hallintaan, A.5.36:n mukaiseen tietoturvapolitiikkojen, -sääntöjen ja -standardien noudattamiseen, A.5.15:n mukaiseen pääsynhallintaan sekä A.8.27:n mukaisiin turvallisen järjestelmäarkkitehtuurin ja suunnittelun periaatteisiin.

Tällä on merkitystä, koska toimittajapalvelut muuttuvat. Tietojen sijainnit muuttuvat. Alikäsittelijät muuttuvat. Haavoittuvuuksia ilmenee. Sertifioinnit vanhenevat. Poikkeamien mallit nousevat esiin. Toimittaja, joka oli hyväksyttävä viime vuonna, voi olla tänään liian riskialtis.

Mitä NIS2:n mukaisten toimittajasopimusten lausekkeiden tulee sisältää

Zenith Blueprint, Kontrollit käytännössä -vaihe, vaihe 23, antaa käytännön kokonaisuuden toimittajasopimusten osa-alueista:

”Toimittajasopimuksissa käsiteltäviä keskeisiä osa-alueita ovat tyypillisesti:

✓ luottamuksellisuusvelvoitteet, mukaan lukien soveltamisala, kesto ja kolmansille osapuolille luovuttamisen rajoitukset; ✓ pääsynhallinnan vastuut, kuten kuka voi päästä tietoihisi, miten tunnistetietoja hallitaan ja millaista seurantaa tehdään; ✓ tekniset ja organisatoriset toimenpiteet tietosuojaa, salausta, turvallista siirtoa, varmuuskopiointia ja saatavuussitoumuksia varten; ✓ poikkeamien raportoinnin määräajat ja menettelyt, usein määritellyillä aikarajoilla (esim. ”ilmoita 24 tunnin kuluessa”); ✓ auditointioikeus, mukaan lukien tiheys, soveltamisala ja pääsy asiaankuuluvaan todentavaan näyttöön (esim. penetraatiotestiraportit, SoA, sertifioinnit); ✓ alihankkijoiden kontrollit, jotka edellyttävät, että toimittaja välittää vastaavat tietoturvavelvoitteet omille jatkokumppaneilleen; ✓ sopimuksen päättymistä koskevat määräykset, kuten tietojen palauttaminen tai tuhoaminen, omaisuuden palautus ja käyttäjätilien poistaminen käytöstä.”

Kontrollit käytännössä -vaiheesta, vaihe 23: organisatoriset kontrollit.

Vahva NIS2-toimittajalauseke on riittävän täsmällinen testattavaksi. ”Toimittajan on ylläpidettävä asianmukaista tietoturvaa” on heikko muotoilu. ”Toimittajan on ilmoitettava asiakkaan tietoturvayhteyshenkilölle 24 tunnin kuluessa vahvistetuista tai epäillyistä poikkeamista, jotka vaikuttavat asiakkaan järjestelmiin, asiakastietoihin, palvelun saatavuuteen tai sääntelyyn perustuviin raportointivelvoitteisiin” on auditoitavissa.

Poikkeamalausekkeiden on vastattava NIS2:n raportointiaikataulua

NIS2 Article 23 luo merkittäville poikkeamille vaiheistetun raportointimallin: varhaisvaroitus 24 tunnin kuluessa tietoon tulemisesta, poikkeamailmoitus 72 tunnin kuluessa, väliraportit pyydettäessä ja loppuraportti yhden kuukauden kuluessa poikkeamailmoituksesta. Merkittävä poikkeama on poikkeama, joka on aiheuttanut tai voi aiheuttaa vakavan operatiivisen häiriön, taloudellisen menetyksen tai huomattavaa aineellista tai aineetonta vahinkoa muille.

Toimittajasopimusten on tuettava tätä aikataulua. Jos kriittiseltä hallinnoidulta palveluntarjoajalta kestää neljä päivää vahvistaa, vaikuttiko tapahtuma asiakasympäristöihin, asiakas voi menettää oman sääntelyn mukaisen ilmoitusikkunansa.

Enterprise-tason Third party and supplier security policy edellyttää:

”Tietoturvaloukkauksista ilmoittamisen määräajat (esim. 24 tai 72 tunnin kuluessa kriittisyyden ja sääntelyvaatimusten mukaan)”

Kohdasta ”Hallintavaatimukset”, politiikkalauseke 5.3.3.

Pk-yrityksille tarkoitettu Third-Party and Supplier Security Policy-sme edellyttää myös määriteltyjä tietoturvaloukkausten ilmoitusmääräaikoja kohdassa ”Hallintavaatimukset”, politiikkalauseke 5.3.3.

PII-poikkeamien osalta Enterprise-tason PII Incident and Breach Management Policy yhdistää kyberturvallisuuteen, finanssialaan, asiakkaisiin ja palvelun vastaanottajiin liittyvän raportoinnin:

”[Ehdollinen] Tietosuojavastaavan / PIMS-päällikön ON koordinoitava kaikki vaaditut alakohtaiset, kyberturvallisuutta koskevat, finanssialan, asiakkaan tai palvelun vastaanottajan poikkeamailmoitukset, kun vaikutuksiltaan merkittävä henkilötietopoikkeama täyttää sovellettavan ilmoituskynnyksen, ja sen ON kirjattava viranomainen, vastaanottaja, aikataulu, toimitus ja kuittausnäyttö REG01- ja REG10-rekistereihin.”

Kohdasta ”Ilmoitukset ja viestintä”, politiikkalauseke 4.4.6.

Tämä on kypsää NIS2-näyttöä: ei pelkkä ilmoitussähköposti, vaan kirjaus viranomaisesta, vastaanottajasta, aikataulusta, toimituksesta, kuittauksesta, vaikutuksesta, juurisyystä ja jatkotoimista.

Tietosuojan ja DORA:n yhteensovittaminen ilman päällekkäisiä toimittajaohjelmia

Monet NIS2-toimittajat käsittelevät myös henkilötietoja. GDPR Article 28 edellyttää, että rekisterinpitäjät käyttävät henkilötietojen käsittelijöitä, jotka antavat riittävät takeet, ja että käsittelijän velvoitteet määritellään kirjallisessa sopimuksessa. GDPR Article 5 edellyttää osoitusvelvollisuutta turvallisesta ja lainmukaisesta käsittelystä. GDPR:n tietoturvaloukkausvelvoitteet edellyttävät myös nopeaa yhteistyötä, kun toimittajapoikkeamat vaikuttavat henkilötietoihin.

Enterprise-tason Processor, Subprocessor and Third-Party Privacy Management Policy asettaa hyväksynnälle hyväksyntäportin:

”[Molemmat] Toimittaja-/hankintaomistajan ON varmistettava ennen hyväksyntää, että henkilötietojen käsittelijöiden ja alikäsittelijöiden sopimukset sisältävät tietosuoja-avun, tietoturvavarmennuksen, PII15:n kautta toteutettavan poikkeamarajapinnan, PII10:n kautta toteutettavan palauttamisen tai poistamisen, PII13:n kautta toteutettavan siirtoyhteyden sekä auditointi- tai varmennusyhteistyön.”

Kohdasta ”Sopimus- ja dokumentoitujen ohjeiden kontrollit”, politiikkalauseke 4.3.6.

Se edellyttää myös näytön katselmointia ennen hyväksyntää:

”[Kaikki] Tietoturvavastaavan ON katselmoitava tietoturvan varmennusnäyttö jokaisesta henkilötietojen käsittelijää, alikäsittelijää tai kolmatta osapuolta koskevasta suhteesta, jossa on pääsy PII:hin tai jossa PII:tä isännöidään, ennen hyväksyntää, ja sen ON kirjattava tulos REG08- tai REG12-rekisteriin.”

Kohdasta ”Huolellisuusarviointi ja riskien arviointi”, politiikkalauseke 4.2.2.

DORA lisää uuden kerroksen, kun toimittaja palvelee finanssialan toimijaa. DORA Articles 28–30 edellyttävät TVT-kolmansien osapuolten hallintaa, TVT-palvelusopimusten rekistereitä, riskiperusteista huolellisuusarviointia, kriittisyyden arviointia, keskittymäriskin analyysiä, auditointi- ja tarkastusoikeuksia, irtisanomisoikeuksia, irtautumisstrategioita ja pakollisia sopimusmääräyksiä. Article 30 on erityisen relevantti, koska se edellyttää sopimussisältöä, joka kattaa palvelukuvaukset, sijainnit, tietosuojan, pääsyn ja palautuksen, palvelutasot, poikkeamissa avustamisen, viranomaisyhteistyön, auditointioikeudet, alihankinnan, varautumistoimenpiteet ja siirtymävaiheen tuen.

Käytännön ratkaisu ei ole kolme erillistä toimittajaohjelmaa NIS2:lle, GDPR:lle ja DORA:lle. Ratkaisu on yksi yhdenmukaistettu toimittajanäyttömalli, joka on kartoitettu eri viitekehyksiin.

NIST CSF 2.0 on hyödyllinen, koska sen GOVERN-toiminto edellyttää riippuvuuksien, lakisääteisten velvoitteiden, sopimusvelvoitteiden, riskinottohalukkuuden, politiikkojen, vastuullisuuden ja valvonnan ymmärtämistä. Sen toimitusketjukategoria GV.SC kattaa toimittajaroolit, kriittisyyden, sopimusvaatimukset, huolellisuusarvioinnin, seurannan, poikkeamien sisällyttämisen, elinkaaren aikaisen seurannan ja suhteen päättymistä koskevat määräykset.

Clarysecin työnkulku kriittisen toimittajan käyttöönottoon

Oletetaan, että otat käyttöön hallinnoidun tietoturvapalvelun tarjoajan, joka seuraa päätelaitetelemetriaa, vastaanottaa käyttäjätunnisteita sisältäviä hälytyksiä ja tukee poikkeamien luokittelua NIS2:n soveltamisalaan kuuluvassa organisaatiossa.

Vaihe 1: luokittele toimittaja

Kirjaa toimittaja toimittajarekisteriin palvelukuvauksen, käytettävien järjestelmien ja tietojen, PII:n käsittelyn, keskeisten tai tärkeiden palvelujen tuen, etuoikeutetun pääsyn, palvelun tuottamisen maiden, alihankkijoiden, neljännen osapuolen riippuvuuksien, kriittisyysluokituksen, riskinomistajan, hankintaomistajan ja tietoturvakatselmoijan kanssa.

Tämä toteuttaa ISO/IEC 27001:2022:n kohdat 4.2, 4.3, 6.1.2 ja 8.1 yhdistämällä sidosryhmävaatimukset, riippuvuudet, riskinomistajuuden ja operatiivisen kontrollin.

Vaihe 2: yhdistä riski SoA:han

Zenith Blueprintin riskienhallintavaiheessa, vaiheessa 13, Clarysec suosittelee sääntelyviittausten ristiinviittaamista riskirekisterissä tai SoA:ssa:

”Ristiinviittaa sääntelyyn: Jos tietyt kontrollit toteutetaan nimenomaisesti GDPR:n, NIS2:n tai DORA:n noudattamiseksi, voit merkitä sen joko riskirekisteriin (osana riskivaikutuksen perustelua) tai SoA:n huomautuksiin.”

Riskienhallintavaiheesta, vaihe 13: riskienkäsittelyn suunnittelu ja soveltuvuuslausunto.

MSSP:n osalta sisällytä vähintään A.5.19, A.5.20, A.5.21, A.5.22, A.5.24–A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 ja A.8.24.

Vaihe 3: edellytä täytäntöönpantavia lausekkeita

Käytä toimittajan tietoturvaliitettä, joka edellyttää 24 tunnin ensimmäistä poikkeamailmoitusta, 72 tunnin yksityiskohtaista päivitystä, lopullista poikkeamaraportointia, MFA:ta etuoikeutetulle pääsylle, nimettyjä käyttäjätilejä, alihankkijakontrolleja, turvallista siirtoa, salausta, varmennusnäyttöä, sääntely-yhteistyötä, BCP- ja DR-näyttöä, irtautumistukea, tietojen palauttamista tai poistamista sekä käyttöoikeuksien perumista.

Enterprise-tason Supplier Dependency Risk Management Policy antaa jatkuvuusvaatimuksen:

”Soveltuvin osin vaatimus siitä, että toimittaja ylläpitää omia liiketoiminnan jatkuvuussuunnitelmiaan (BCP/DRP) ja poikkeamienhallintasuunnitelmiaan, testaa niitä ja toimittaa meille pyynnöstä yhteenvedot tai testiraportit.”

Kohdasta ”Toteutusvaatimukset”, politiikkalauseke 6.8.4.

Vaihe 4: kokoa varmennusnäyttöpaketti

Pyydä ennen hyväksyntää allekirjoitettu sopimus, SLA, tietoturvaliite, ISO/IEC 27001:2022 -sertifioinnin soveltamisala tai vastaava varmennus, SOC-raportti silloin kun se on saatavilla, penetraatiotestin johdon yhteenveto, haavoittuvuuksien hallinnan yhteenveto, tietoturvapoikkeamiin reagoinnin menettelyn yhteenveto, BCP- tai DR-testin yhteenveto, pääsynhallinta- ja MFA-vakuutus, alihankkijaluettelo, tietojen poistamisen ja irtautumisen menettely sekä DPA silloin, kun PII:tä käsitellään.

Pk-yrityksille tarkoitettu Third-Party and Supplier Security Policy-sme tekee sopimusnäytön perustasosta mitattavan:

”Allekirjoitetut sopimukset ja SLA:t”

Kohdasta ”Soveltaminen ja vaatimustenmukaisuus”, politiikkalauseke 8.3.2.1.

Se tunnistaa myös toistuvan toimittajanäytön:

”Voimassa olevat tietoturvasertifioinnit tai päivitetty kontrollinäyttö”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.3.1.2.

Laajemman toimittajahuolellisuusarvioinnin osalta Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka toteaa:

”Toimittajahuolellisuusarvioinnin tulee sisältää sertifiointien (esim. ISO 27001, SOC 2), tietoturvakyselyjen ja poikkeamatallenteiden katselmointi.”

Vaihe 5: seuraa kriittisyyden perusteella

Enterprise-tason Processor, Subprocessor and Third-Party Privacy Management Policy edellyttää neljännesvuosittaista seurantaa korkean riskin PII-suhteille:

”[Kaikki] Toimittaja-/hankintaomistajan ON seurattava aktiivisia korkean riskin henkilötietojen käsittelijä- ja alikäsittelijäsuhteita neljännesvuosittain sekä muita aktiivisia PII-käsittelijä- ja alikäsittelijäsuhteita vuosittain REG08-rekisterissä olevien huolellisuusarvioinnin ehtojen, sopimustilan, varmennustilan, avoimien asioiden ja katselmointipäivämäärien perusteella.”

Kohdasta ”Jatkuva seuranta, avustaminen, luovutusrajapinta ja irtautuminen”, politiikkalauseke 4.5.1.

Näin A.5.22 muuttuu todelliseksi toiminnaksi. Katselmoinnissa tulee määrittää, pysyykö toimittaja riskinottohalukkuuden rajoissa, onko näyttö ajantasaista, onko avoimia asioita, onko poikkeamia tapahtunut ja edellyttävätkö palvelumuutokset uudelleenarviointia.

Miten auditoijat testaavat NIS2:n mukaisia toimittajalausekkeita

Auditoijat aloittavat harvoin lukemalla politiikkaasi erillään muusta kokonaisuudesta. He ottavat otoksen toimittajista ja seuraavat näyttöketjua.

ISO/IEC 27001:2022 -auditoija pyytää toimittajainventaarion, riskiluokittelun, toimittajakriteerit, huolellisuusarvioinnin tallenteet, sopimukset, näytön, SoA-vastaavuudet ja seurantahistorian. Liite A 5.20:n osalta auditoija tarkastaa, sisältävätkö otokseen valitut sopimukset täytäntöönpantavia lausekkeita. Liite A 5.22:n osalta auditoija testaa, onko raportit katselmoitu, poikkeukset kirjattu ja toimenpiteitä seurattu.

NIS2-toimivaltainen viranomainen voi keskittyä siihen, onko toimittajien kyberturvallisuuskäytännöt ja turvallisen kehittämisen menettelyt arvioitu Article 21(3):n mukaisesti. DORA-painotteinen arvioija voi pyytää TVT-sopimusrekisterimerkintöjä, irtautumisstrategioita, keskittymäriskin analyysiä ja pakollisia Article 30:n määräyksiä. Tietosuoja-auditoija voi testata henkilötietojen käsittelijöiden sopimuksia, alikäsittelijöille ketjutettavia velvoitteita, tietoturvaloukkausten rajapintoja ja näyttöä riittävistä takeista.

Enterprise-tason PII Security and Access Control Policy osoittaa, miten pääsynhallinta, haavoittuvuudet, konfiguraatio, seuranta ja kryptografia linkittyvät takaisin ISO/IEC 27001:2022 -standardiin:

”ISO/IEC 27001:2022 — kohta 6.1.3; kohta 8.1; liite A:n kontrollit 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Käsitelty lausekkeissa [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

Kohdasta ”Viitestandardit ja viitekehykset”, politiikkalauseke 13.9.

Kun toimittajalla on pääsy PII:hin, etuoikeutettuihin järjestelmiin tai seurantatietoihin, pääsynhallinnan näyttö ei ole erillään toimittajavarmennuksesta. Se on osa samaa auditointijälkeä.

Hankinnan ansa: allekirjoitetut sopimukset ilman varmennustoimintaa

Yleisin NIS2-toimittajahallinnan epäonnistuminen ei ole sopimusten puuttuminen. Se on kuilu sopimuskielen ja päivittäisen toiminnan välillä.

Sopimus voi edellyttää vuosittaisia penetraatiotestien yhteenvetoja, mutta mikään omistaja ei pyydä niitä. Se voi edellyttää 24 tunnin poikkeamailmoitusta, mutta toimittajalla on vain yleinen tukiosoite. Se voi edellyttää alihankkijoiden hyväksyntää, mutta hankinta ei koskaan saa muutosilmoituksia. Se voi sisältää auditointioikeudet, mutta organisaatiolla ei ole prosessia SOC-raporttien poikkeusten arviointiin. Se voi edellyttää tietojen poistamista irtautumisen yhteydessä, mutta IT ei koskaan validoi käyttäjätilien käytöstäpoistoa.

Zenith Blueprint, Kontrollit käytännössä -vaihe, vaihe 23, selittää, miten toimittajakontrollit muuttuvat toiminnaksi:

”Käytännössä tämä kontrolli toteutuu seuraavien kautta:

✓ toimittajariskien arvioinnit, ✓ ennen toimeksiantoa tehtävät huolellisuusarvioinnin kyselyt, ✓ sopimusmallit, joihin on sisällytetty tietoturvaehdot, ✓ toimittajan käyttöönoton tarkistuslistat, jotka sisältävät käyttöoikeuksien myöntämisen ja seurannan käyttöönoton, ✓ jatkuvat uudelleenarvioinnit erityisesti silloin, kun toimittajan soveltamisala muuttuu, poikkeamia tapahtuu tai uusimiset tulevat ajankohtaisiksi.

Tämä kontrolli ei myöskään pääty ensimmäisen tason toimittajiin. Toimittajasi voi ulkoistaa omille palveluntarjoajilleen, ja riski voi silti jäädä sinun vastuullesi.”

Tämä on hallitustason NIS2-viesti: palvelun tuottamisen ulkoistaminen ei ulkoista vastuuta.

NIS2:n mukaisten toimittajasopimusten korjaustoimien tarkistuslista

Aloita kriittisyyden perusteella 20 tärkeimmästä toimittajasta ja toteuta kohdennettu korjausharjoitus:

• Tunnista toimittajat, jotka tukevat keskeisiä tai tärkeitä palveluja.
• Vahvista, käsitteleekö kukin toimittaja PII:tä, tukeeko se sääntelyn alaisia palveluja tai onko sillä etuoikeutettu pääsy.
• Nimeä liiketoimintavastaava, hankintaomistaja ja tietoturvakatselmoija.
• Varmista, että toimittajariskien arviointi on ajantasainen ja vastaa todellista palvelun soveltamisalaa.
• Vahvista, että sopimus sisältää tietoturvan perustason, poikkeamailmoituksen, auditointi- tai näyttöoikeudet, alihankkijakontrollit, jatkuvuuden, turvallisen siirron, pääsynhallinnan, haavoittuvuuksien käsittelyssä tehtävän yhteistyön ja irtautumislausekkeet.
• Vahvista, että tietoturvaloukkausten määräajat tukevat 24 ja 72 tunnin eskalointitarpeita soveltuvissa tilanteissa.
• Pyydä päivitetty varmennusnäyttö, mukaan lukien sertifioinnit, SOC-raportit, penetraatiotestien yhteenvedot, BCP- tai DR-testit ja poikkeamahistoria.
• Katselmoi näyttö; älä pelkästään tallenna sitä.
• Kirjaa poikkeukset ja nimeä korjaustoimien omistajat.
• Päivitä SoA ja riskirekisteri silloin, kun toimittajakontrollit tukevat NIS2-, GDPR-, DORA- tai asiakassitoumuksia.
• Aikatauluta seurannan tiheys toimittajan kriittisyyden perusteella.
• Testaa yhden toimittajan poikkeaman eskalointipolku.
• Testaa yhden toimittajan päättämispolku, mukaan lukien tietojen palauttaminen, poistaminen, omaisuuden palautus ja käyttöoikeuksien peruminen.

Jos et pysty osoittamaan näitä asioita kriittisen toimittajan osalta, sopimus ei ole vielä auditointivalmis.

Muuta toimittajalausekkeet valvontaviranomaisille esitettäväksi näytöksi

NIS2:n mukainen toimittajahallinta on nyt elävä operatiivinen kurinalaisuus. Valvontaviranomaiset, asiakkaat, sertifiointiauditoijat, tietosuojatiimit, finanssialan kumppanit ja hallitukset eivät kysy ainoastaan, ovatko toimittajalausekkeet olemassa. Ne kysyvät, ovatko lausekkeet riskiperusteisia, täytäntöönpantavia, seurattuja, todennettuja ja liitettyjä poikkeamien raportointiin, jatkuvuuteen, pääsynhallintaan, haavoittuvuuksien hallintaan, alihankkijoille ketjutettaviin velvoitteisiin ja irtautumiseen.

Clarysec auttaa organisaatioita sulkemaan tämän kuilun Zenith Blueprintin avulla muuttamalla toimittajakontrollit ISMS-vaiheiksi, riskien käsittelyksi, SoA-merkinnöiksi, käyttöönoton rutiineiksi ja auditointinäytöksi. Zenith Controls yhdistää ISO/IEC 27002:2022 -standardin toimittajakontrollit A.5.19, A.5.20 ja A.5.22 NIS2-, DORA-, GDPR-, NIST- ja COBIT 2019 -vaatimuksiin, tukeviin ISO-standardeihin ja auditointimenetelmiin. Clarysecin toimittaja- ja tietosuojapolitiikat tarjoavat lausekerakenteen, näyttöodotukset ja seurantakäytännöt, joiden avulla toimittajavarmennuksesta tulee puolustettavissa.

Seuraava toimenpiteesi on yksinkertainen: valitse viisi kriittistä toimittajaa, ota otos niiden sopimuksista, yhdistä jokainen lauseke ISO/IEC 27001:2022 -riskien käsittelyyn ja liite A:n kontrolleihin, pyydä tuore varmennusnäyttö ja toteuta 24 tunnin poikkeamailmoituksen pöytäharjoitus. Jos näyttöketju katkeaa, Clarysecin työkalupaketit antavat rakenteen sen korjaamiseen ennen kuin poikkeama, asiakaskatselmointi tai valvontaviranomaisen pyyntö tekee sen puolestasi.