Miksi MSP:n ICT-toimitusketjut muokkaavat nyt suurimpia turvallisuusriskejäsi

Miksi MSP-toimitusketjut ovat nyt suurin hyökkäyspintasi

Nykyaikaiset hallittujen palvelujen tarjoajat kohtaavat kasvavia riskejä ICT-toimitusketjuista, eivätkä vain omista datakeskuksistaan. Ylävirran työkaluista, alustoista ja kumppaneista voi tulla yksittäisiä vikaantumiskohtia, jotka vaarantuessaan tai ollessaan käyttämättömiä vaikuttavat samanaikaisesti moniin asiakkaisiin ja palveluihin. Liite A.5.21 auttaa sinua ymmärtämään näitä riippuvuuksia, sopimaan selkeistä tietoturvaodotuksista toimittajien ja asiakkaiden kanssa sekä käsittelemään toimitusketjun riskiä tietoturvan hallintajärjestelmän tarkoituksellisena osana eikä jälkikäteen harkittuna.

Monille hallittujen palvelujen tarjoajille työkalujen, alustojen ja kumppaneiden toimitusketjusta on tullut yksi ympäristön riskialttiimmista osista oman datakeskuksen ohella. Nämä jaetut komponentit ovat tulosi, sopimuksesi ja sääntelyyn liittyvät lupauksesi perusta. Kun yksi niistä vikaantuu tai vaarantuu, vaikutukset voivat levitä useille asiakkaille tunneissa, minkä vuoksi liite A.5.21 on niin tärkeä, jotta tästä riippuvuuksien verkostosta voi tehdä tietoisen suunnittelun ja hallinnan.

Nykyaikaiset MSP:t perivät riskin etähallinta-alustojen, pilvipalveluiden, identiteetintarjoajien ja sinun ja asiakkaidesi välissä olevien niche-työkalujen usean käyttäjän luonteesta. Yksikin ylävirran kompromittointi voi antaa hyökkääjälle etuoikeutetun pääsyn suureen osaan asiakaskuntaasi. Vastaavasti ydinalustan käyttökatkos voi viedä useita asiakkaita offline-tilaan kerralla riippumatta siitä, kuinka hyvin oma infrastruktuurisi toimii.

Vahvat toimitusketjut alkavat siitä, että tiedät, kenestä olet todella riippuvainen.

MSP:n toimitusketjun riskien uusi todellisuus

Hallittujen palveluntarjoajien (MSP) uusi todellisuus on, että hyökkääjät ja käyttökatkokset kulkevat nyt jaettujen ICT-alustojen kautta nopeammin kuin yksittäisten asiakkaiden verkkojen kautta. Kun etähallintatyökaluja, pilvipalveluita, identiteettialustoja ja tietoturvatuotteita pinotaan tarjontaansa, jokaisesta jaetusta komponentista tulee mahdollinen yksittäinen vikaantumispiste. Liite A.5.21 on suunniteltu auttamaan sinua tunnistamaan tämän todellisuuden ja rakentamaan sen ympärille oikeasuhtaisia valvontakeinoja.

Nykyaikaiset MSP:t perivät suurimman osan toimitusketjun riskeistään pilvialustoilta, SaaS-työkaluilta ja alihankkijoilta, joita ne sisällyttävät palveluihinsa. Uusien tarjousten kokoamisen yhteydessä on luonnollista lisätä erikoistuneita alustoja, valvontatyökaluja, varmuuskopiointipalveluntarjoajia ja tietoturvapalveluita ydinominaisuuksien lisäksi.

Tietoturvan tila 2025 -raportti osoittaa, että useimmissa organisaatioissa on ollut viimeisen vuoden aikana ainakin yksi kolmannen osapuolen tai toimittajan aiheuttama tietoturvahäiriö.

Ajan myötä tämä kasvu luo tiheitä, monitasoisia riippuvuusketjuja: etävalvontatyökaluja julkisen pilven päällä, asiakasvuokralaisiin linkitettyjä identiteettialustoja, varmuuskopiointipalveluntarjoajia, jotka replikoivat tietoja alueiden välillä, ja API-rajapintojen kautta integroituja erikoistuneita tietoturvatyökaluja. Hyökkääjien ei tarvitse kohdistaa hyökkäyksiä jokaiseen asiakkaaseen erikseen. Yhden ylävirran palvelun vaarantaminen voi antaa etuoikeutetun pääsyn moniin hallittuihin ympäristöihin tai sallia kiristysohjelmien leviämisen nopeasti samoja työkaluja jakavien asiakkaiden välillä. Ohjelmistojen toimitusketjutapahtumien analyysit kuvaavat juuri tätä kaavaa, jossa laajalti käytetyn toimittajan tai komponentin vaarantuminen voi vaikuttaa suureen määrään alavirran organisaatioita kerralla (ohjelmistojen toimitusketjuhyökkäysanalyysi).

Katkokset toimivat samalla tavalla. Keskitetyn identiteetintarjoajan tai etähallintapinon vika voi viedä useita asiakkaita pois verkosta, laukaista sopimussakot ja kiinnittää sääntelyviranomaisten huomion, vaikka oma infrastruktuuri ei vaikuttaisikaan. Toimitusketjun kyberturvallisuusriskien arviointia ja hallintaa koskevat alan ohjeistukset korostavat usein, kuinka jaettujen pilvi- tai identiteettipalveluiden häiriöt tai vaarantuminen voivat aiheuttaa samanaikaisia katkoksia ja liiketoimintavaikutuksia useille asiakkaille, sekä sopimus- ja sääntelyseurauksia niistä riippuvaisille palveluntarjoajille (toimitusketjun kyberturvallisuusriskien yleiskatsaus). Liite A.5.21 on suunnattu suoraan tälle yhdistetylle tekniselle ja sopimukselliselle haavoittuvuuksille, ei vain yksittäisille haavoittuvuuksille.

Monien MSP-palveluntarjoajien tietoturvamittarit eivät ole pysyneet tämän muutoksen mukana. Tiimit seuraavat edelleen perimetritapahtumia, korjauspäivitysten määrää ja päätepistehälytyksiä, mutta niillä on vain vähän näkyvyyttä perittyjä haavoittuvuuksia tai toimittajien aiheuttamia häiriöitä. Ilman selkeää kuvaa ylävirran riippuvuuksista ja niiden riskiprofiileista toimitaan käytännössä sokkona niissä paikoissa, joissa viat todennäköisimmin vahingoittavat toimintaansa. Siksi tarvitaan toimitusketjunäkymiä tietoturvanhallintajärjestelmässä pelkkien verkkomittareiden sijaan.

Missä näkyvyys todella heikkenee

Näkyvyys yleensä pettää "varjo"toimitusketjussa: työkaluissa, palveluissa ja kumppaneissa, jotka livahtivat mukaan virallisen hankinnan ulkopuolelle. Nämä näyttävät usein tuolloin kertaluonteisilta päätöksiltä, mutta niistä tulee osa pysyvää riippuvuussuhdetta.

Useimmat hallinnoidut palveluntarjoajat (MSP) pystyvät listaamaan ensisijaiset toimittajansa muistinvaraisesti, mutta harvat pystyvät antamaan täydellisen kuvan siitä, kehen ja mihin he todella luottavat. Insinöörien käyttöön ottamat freemium-palvelut, "väliaikaiset" pilottityökalut, jotka eivät koskaan päättyneet, ja asiakkaan määräämät alustat, joita olet suostunut tukemaan, lisäävät kaikki tätä piilotettua tasoa.

Ongelmana on, että hyökkääjät ja sääntelyviranomaiset eivät välitä siitä, onko riippuvuus virallisesti hyväksytty vai hiljaisesti omaksuttu. Jos kompromissi välittyy sen kautta hallittuihin ympäristöihisi, asiakkaat odottavat silti vastauksia sinulta. Liite A.5.21 käsittelee näitä suhteita laajuusluokassa. Se odottaa, että tuot ne toimitusketjukarttaasi, luokittelet ne ja päätät, mitä "riittävän turvallinen" tarkoittaa kullekin riskin perusteella.

Käytännössä ensimmäinen askel on kartoittaa kriittisimpien jaettujen komponenttien toimintasäde. Arvioi jokaiselle merkittävälle työkalulle tai alustalle, kuinka monta asiakasta, minkä tyyppiset tiedot ja mitkä palvelut ovat siitä riippuvaisia. Kun huomaat yhden etähallintapinon muodostavan merkittävän osan tuloistasi, toimitusketjun riski lakkaa tuntumasta abstraktilta ja alkaa vaatia strukturoituja valvontatoimia.

Miksi hallituksesi tulisi välittää yhtä paljon kuin insinööriesi

Hallituksesi ja ylimmän johdon on nähtävä ICT-toimitusketjun turvallisuus hallintokysymyksenä, ei vain insinöörien teknisenä huolenaiheena. Asiakkaat, vakuutusviranomaiset ja sääntelyviranomaiset kysyvät yhä useammin, miten kolmansien osapuolten ja ulkoistettujen IT-riskien tunnistaminen, arviointi ja hallinta tapahtuu, ja he odottavat johdonmukaisia vastauksia, jotka ulottuvat turvallisuustiimiä pidemmälle. Ohjelmistoja ja ICT-toimitusketjun uhkia seuraavat alan elimet huomauttavat, että ulkoiset sidosryhmät kiinnittävät entistä enemmän huomiota siihen, miten organisaatiot hallitsevat kolmansien osapuolten riskejä, eivätkä vain siihen, mitä teknologioita ne käyttävät (kasvava uhka ohjelmistojen toimitusketjuhyökkäyksille).

Vuoden 2025 ISMS.online-kyselyn mukaan asiakkaat odottavat yhä useammin toimittajien noudattavan virallisia viitekehyksiä, kuten ISO 27001, ISO 27701, GDPR tai SOC 2, sen sijaan, että ne luottaisivat yleisiin hyviin käytäntöihin.

Kun sidosryhmät ymmärtävät, että hallinnoidut palvelusi ovat muiden palveluntarjoajien, jotka itse saattavat olla kohteiden joukossa, päällä, he etsivät todisteita siitä, että ymmärrät ja hallitset näitä linkkejä. Toimitusketjun turvallisuudesta tulee hallituksen tason aihe, koska siinä tapahtuvat epäonnistumiset voivat samanaikaisesti aiheuttaa liiketoiminnan keskeytymistä, sääntelyvalvontaa ja maineen vahingoittumista.

Johtaminen tarvitsee tyypillisesti varmuuden siitä, että:

Kriittiset ylävirran työkalut ja kumppanit tunnistetaan, riskiarvioidaan ja heidät sidotaan sopimuksellisesti selkeisiin tietoturvaodotuksiin.
Organisaatio ymmärtää, mihin asiakkaisiin ja palveluihin tietyt alkupään häiriöt vaikuttaisivat.
Toimittajatapahtumille on olemassa testattuja toimintaohjeita, jotka kattavat teknisen reagoinnin, viestinnän ja sopimusvelvoitteet.

Ilman tätä varmuutta vaikeat kysymykset päätyvät johtokuntahuoneeseen pahimpaan mahdolliseen aikaan: käyttökatkoksen, tietomurron tai auditoinnin aikana. Liitteen A.5.21 käsittely ICT-toimitusketjun varmennuksen virallisena selkärankana antaa johtajille standardipohjaisen pohjan, johon he voivat luottaa paineen alla improvisoitujen selitysten sijaan.

Varaa demo

Liite A.5.21 ja uusi ICT-toimitusketjun varmuuden määritelmä

Liitteessä A.5.21 sinua pyydetään sopimaan, dokumentoimaan ja ylläpitämään asianmukaisia tietoturvaodotuksia ICT-toimittajien ja -asiakkaiden kanssa, joista olet riippuvainen. Käytännössä sinun tulisi tietää, kehen luotat, mitä odotat heiltä, mitä he odottavat sinulta ja miten näitä odotuksia tarkistetaan ajan kuluessa. Hallitun palveluntarjoajan kannalta tämä tarkoittaa sen tunnustamista, että olet osa useiden asiakkaiden ICT-toimitusketjuja, sekä omien toimitusketjujesi hallintaa. Tämä heijastaa tapaa, jolla ISO/IEC 27001:2022 kuvaa kontrollia A.5.21 ICT-toimitusketjujen tietoturvakontrollien luettelossaan (ISO/IEC 27001:2022 -yleiskatsaus).

Lähes kaikki vuoden 2025 ISMS.online-kyselyyn osallistuneet organisaatiot mainitsivat tärkeimpänä prioriteettinaan tietoturvasertifikaattien, kuten ISO 27001- tai SOC 2 -standardin, hankkimisen tai ylläpitämisen.

Vakavasti ottaen liite A.5.21 siirtää ICT-toimitusketjun varmuuden mutu-tuntumasta riskiperusteiseen, dokumentoituun käytäntöön. Se perustuu laajempaan liitteen A kontrollien perheeseen toimittajasuhteita, sopimuksia ja valvontaa varten ja soveltaa niitä erityisesti ICT-tuotteisiin ja -palveluihin. Ymmärtämällä, miten se sopii yhteen kohtien A.5.19, A.5.20 ja A.5.22 kanssa, saat viitekehyksen tämän tekemiseen ilman, että koko tietoturvanhallintajärjestelmääsi tarvitsee uudistaa.

Integroitu tietoturvallisuuden hallintajärjestelmä (ISMS), kuten ISMS.online, voi auttaa sinua pitämään kuvan yhdessä paikassa linkittämällä toimittajat, asiakkaat, palvelut, riskit ja liitteen A mukaiset kontrollit, jotta niitä on helppo tarkastella ja päivittää liiketoimintasi kehittyessä.

Nämä tiedot ovat yleisiä eivätkä ne ole oikeudellista neuvontaa; organisaatioiden tulisi hakea asianmukaista ammatillista ohjausta sääntelyyn liittyvien päätösten tekemiseksi.

Mitä liite A.5.21 todellisuudessa odottaa

Liite A.5.21 edellyttää, että käsittelet ICT-toimitusketjun turvallisuutta jatkuvana, jaettuna vastuuna eikä kertaluonteisena sopimusehtona. Se vahvistaa ajatusta, että odotusten tulisi olla riskiperusteisia, dokumentoituja ja ylläpidettäviä ajan kuluessa sen sijaan, että ne oletetaan tai asetetaan kerran ja unohdetaan. Hallittujen palveluntarjoajien kannalta tämä tarkoittaa odotusten suunnittelua sekä alku- että loppupään toimitusketjussa ja sen tarkistamista, että ne ovat edelleen järkeviä palveluiden ja riskien muuttuessa.

Liite A.5.21 sijaitsee kolmen läheisesti toisiinsa liittyvän valvonnan rinnalla:

A.5.19, joka kattaa toimittajasuhteita koskevat käytännöt.
A.5.20, joka keskittyy varmistamaan, että tietoturva otetaan huomioon toimittajasopimuksissa.
A.5.22, joka käsittelee toimittajapalveluiden seurantaa, tarkastelua ja muutoshallintaa.

Yhdessä nämä kontrollit voidaan lukea arkikielellä seuraavasti: tunnista ICT-toimitusketjusi, määrittele siltä odottamasi tietoturvavaatimukset, sisällytä nämä vaatimukset toimittajien valintaan, sopimusten tekemiseen ja valvontaan sekä pidä valvonta käynnissä palveluiden muuttuessa. Liitteessä A.5.21 tämä koskee erityisesti ICT-palveluita ja -tuotteita sekä alku- että loppupäässä. Nämä kontrollien otsikot ja ryhmittelyt noudattavat standardissa ISO/IEC 27001:2022 julkaistua rakennetta, jossa esitetään liitteen A kontrollit ja niiden painopistealueet toimittajien ja ICT-toimitusketjun turvallisuuden osalta (ISO/IEC 27001:2022 -yleiskatsaus).

Hallitun palveluntarjoajan (MSP) kohdalla on vielä yksi lisäjuttu. Olet sekä asiakas että toimittaja. Luotat ylävirran ICT-palveluihin tarjontasi toimittamisessa ja olet kriittinen toimittaja asiakkaidesi omissa ICT-toimitusketjuissa. Liite A.5.21 edellyttää, että hallitset molempia osapuolia johdonmukaisesti tavalla, joka heijastaa riskejä ja on osa jokapäiväisiä prosesseja eikä sitä käsitellä erillisissä asiakirjoissa.

Standarditekstin muuttaminen ymmärrettäväksi kaikille

Tiimisi sitoutuvat todennäköisemmin, jos käännät standardin sanaston pieneksi joukoksi selkeitä ja käytännönläheisiä sitoumuksia. Näiden sitoumusten tulisi kuvata, mitä käytännössä teet, termein, jotka insinöörit, asiakkuuspäälliköt ja lakitiimit ymmärtävät, sen sijaan, että ne lainaisivat standardia.

Voit muotoilla liitteen A.5.21 uudelleen sitoumuksina, kuten:

”Valvomme ja luokittelemme käyttämämme ICT-toimittajat ja -alustat ja käytämme niitä, kun ne täyttävät sovitut turvallisuuskriteerit.”
”Määrittelemme ja dokumentoimme, kuka on vastuussa mistäkin turvatoimista jokaisessa myymässämme hallitussa palvelussa.”
”Seuraamme keskeisiä toimittajia ja palveluita ajan kuluessa ja reagoimme nopeasti ja läpinäkyvästi, kun jokin muuttuu tai menee pieleen.”

Kun nämä käännökset ovat valmiit, on paljon helpompi nähdä, missä liitteen A.5.21 osia on jo käytössä, kuten toimittajien perehdytystarkastukset, sopimusmallit tai säännölliset arvioinnit. Se korostaa myös sitä, missä käytännöt ovat ad hoc -pohjaisia, dokumentoimattomia tai riippuvat yksittäisestä henkilöstöstä. Tämä kartoitus antaa lähtökohdan yksityiskohtaisemmalle suunnittelutyölle sekä alku- että loppupäässä.

Liitteessä A.5.21 oletetaan, että vaatimuksesi ovat oikeassa suhteessa riskiin sen sijaan, että niitä kopioitaisiin sokeasti suhteesta toiseen. Vaikutukseltaan suuret toimittajat ja asiakkaat tarvitsevat yleensä perusteellisempaa huolellisuutta ja tiukempia velvoitteita kuin vähemmän vaikuttavat toimittajat ja asiakkaat, ja sama periaate tekee loppupään sopimuksistasi paremmin puolustettavissa sääntelyviranomaisten ja tilintarkastajien silmissä.

Valvonta ei tarkoita, että sinun on asetettava samanlaiset yksityiskohtaiset turvallisuusodotukset jokaiselle toimittajalle tai asiakkaalle. Se edellyttää, että perustelet odotuksesi riskin valossa. Kriittinen pilvialusta, joka isännöi asiakastietoja, vaatii perusteellisempia due diligence -tarkastuksia, vahvempia sopimusehtoja ja intensiivisempää valvontaa kuin matalan riskin, ei-kriittinen työkalu.

Sama logiikka pätee myös alavirtaan. Sairaalalle tai rahoituslaitokselle toimitettavaan hallinnoituun palveluun liittyy erilaisia velvoitteita ja valvontaa kuin pienelle, sääntelemättömälle yritykselle toimitettavaan palveluun. Liitteen A.5.21 täytäntöönpano on uskottavaa, kun nämä erot näkyvät riskinarvioinneissasi ja sopimusten jäsentämisessäsi, ei silloin, kun jokaisessa suhteessa käytetään kopioi-ja-liitä-muotoilua vaikutuksesta riippumatta.

Liitteen A.5.21 yhdenmukaistaminen jo käyttämiesi kehysten, kuten SOC 2:n, tunnustettujen kyberturvallisuusohjeiden tai kansallisten toimitusketjusuositusten, kanssa voi auttaa. Tietoturvatoimittajien ja -ammattilaisten toimitusketjua koskevat parhaat käytännöt kannustavat sinua kartoittamaan yhteisiä valvontatavoitteita standardien, kuten ISO 27001:n, SOC 2:n ja kansallisten kyberturvallisuuskehysten, välillä, jotta tiimit eivät ylläpidä useita, ristiriitaisia vaatimuskokonaisuuksia (yleiskatsaus toimitusketjun tietoturvakäytäntöihin). Tässä "porrastaminen" tarkoittaa yksinkertaisesti toimittajien ja asiakkaiden ryhmittelyä muutamaan vaikutusperusteiseen tasoon sen sijaan, että kutakin suhdetta käsiteltäisiin ainutlaatuisena.

ISMS.online antaa sinulle 81 %:n etumatkan heti sisäänkirjautumisestasi lähtien.

ISO 27001 helposti

Olemme tehneet kovan työn puolestasi ja antavat sinulle 81 % etumatkan kirjautuessasi sisään. Sinun tarvitsee vain täyttää tyhjät kohdat.

Aloita

Ylävirran ja alavirran säätimet MSP-kontekstissa

Hallitun toimitusketjun suunnitelmassa (MSP) ”upstream” kattaa toimittajat, alustat ja alihankkijat, joihin luotat, kun taas ”downstream” kattaa asiakkaat ja vuokralaiset, jotka ovat riippuvaisia sinusta. Liite A.5.21 on helpompi toteuttaa, kun näitä suhteita käsitellään erillisinä mutta toisiinsa linkitettyinä, selkeillä vastuilla ja odotuksilla molempiin suuntiin. Tämä rakenne muuttaa abstraktit toimitusketjun huolenaiheet sopimuksiksi, toimintaohjeiksi ja koontinäytöiksi, joiden pohjalta ihmiset voivat toimia.

Selkeä ylä- ja alavirran malli muuttaa vakiotekstin toimiviksi sopimuksiksi, toteutuskirjoiksi ja koontinäytöiksi. Voit määrittää, miten valitset ja valvot toimittajia, miten jaat vastuun asiakkaiden kanssa ja miten reagoit, kun ongelmia ilmenee kumpaankin suuntaan. Kun tämä rakenne on paperilla, sen toteuttaminen työkaluissa ja toiminnassa on paljon yksinkertaisempaa.

Ylävirran, alavirran ja hybridisuhteiden määrittely

Ensimmäinen tehtäväsi on nimetä ja luokitella ulkoiset suhteet, joista olet riippuvainen, sen sijaan, että käsittelisit niitä kaikkia yleisinä "toimittajina" tai "asiakkaina". Tämä luokittelu muokkaa sitä, mitkä liitteen A.5.21 osat soveltuvat vahvimmin ja mihin suunnittelutyösi tulisi keskittää. Se luo myös yhteisen kielen organisaatiosi sisällä, kun keskustelet toimitusketjun riskistä.

Aloita listaamalla ulkoiset osapuolet ja luokittelemalla ne kahden ulottuvuuden mukaan: toimittavatko he sinulle vai sinä toimitat heille, ja kuinka kriittisiä he ovat palveluillesi? Ylävirran ICT-toimittaja voi olla pilvi-infrastruktuurin tarjoaja, etävalvontatyökalu, varmuuskopiointialusta tai erikoistunut tietoturvakumppani. Alavirran osapuolet ovat hallittujen palveluiden asiakkaitasi, mukaan lukien ne, joissa toimit tietojen käsittelijänä tietosuojalainsäädännön nojalla.

Jotkin suhteet ovat hybridirakenteisia. Yhteishallintaratkaisussa oleva vertaishallintapalveluntarjoaja sekä toimittaa sinulle tiettyjä ominaisuuksia että on vastineeksi riippuvainen palveluistasi. Asiakas, joka isännöi omaa pilvivuokraajaansa, mutta pyytää sinua hallinnoimaan sitä, hämärtää rajaa asiakasalustan ja ylävirran ympäristön välillä. Nämä hybridit vaativat erityistä huolellisuutta, koska on helppo ottaa tärkeitä vastuita molemmille osapuolille tai ei kummallekaan.

Kun nämä roolit on kirjattu, voit alkaa määritellä, mitkä valvontaluokat koskevat mitäkin rooleja. Ylävirran suhteissa keskeisessä asemassa ovat due diligence, turvallinen tekninen integraatio, tietoturvaloukkausilmoitus ja alihankkijoiden valvonta. Alavirran suhteissa jaettu vastuu, perustason tietoturvaodotukset ja asiakasvelvoitteet ovat tärkeämpiä. Hybridijärjestelyt edellyttävät yhdistelmää ja erittäin selkeitä rajoja aukkojen välttämiseksi.

Riskiperusteisten tasojen käyttö rakenteen luomiseksi

Riskiperusteiset tasot muuttavat pitkän toimittaja- ja asiakasluettelon työstettäväksi kokonaisuudeksi. Ryhmittelemällä suhteet muutamiin vaikutusperusteisiin luokkiin voit määrittää kullekin tasolle vakiomuotoiset ohjausjoukot sen sijaan, että suunnittelisit jokaisen suhteen alusta alkaen.

Voit esimerkiksi luoda kolme tasoa ylävirran toimittajille:

Taso 1: kriittiset alustat, joilla on etuoikeutettu pääsy tai jotka isännöivät asiakastietoja.
Taso 2: tärkeät tukipalvelut, joilla on rajoitettu suora pääsy asiakasjärjestelmiin.
Taso 3: vähäriskiset työkalut, joilla ei ole pääsyä arkaluonteisiin tietoihin tai tuotantoympäristöihin.

Alavirrassa voit ottaa käyttöön tasoja, kuten ”säännelty”, ”korkea käytettävyys” ja ”vakio”, tietojen arkaluonteisuuden ja käyttökatkosten liiketoimintavaikutusten perusteella.

Jokainen ylä- ja alavirran tasojen yhdistelmä asettaa erilaisia odotuksia. Säännellyn terveydenhuollon asiakkaan perustana oleva tason 1 ylävirran alusta vaatii syvempää varmuutta ja tiukempia valvontatoimia kuin standardiasiakasta tukeva tason 2 työkalu. Näiden yhdistelmien dokumentointi yksinkertaisilla malleilla – esimerkiksi ”MSP–hyperskaalaaja–säännelty asiakas” vs. ”MSP–jakelija–MSP–yritys” – antaa sinun suunnitella vakiomuotoisia valvontatoimia sen sijaan, että aloittaisit tyhjästä jokaisen uuden suhteen osalta.

Ytimekäs tapa visualisoida tätä on pienen matriisin avulla, joka näyttää, miten vastuut vaihtelevat suhteiden tyypin mukaan.

Suhteen tyyppi	Ylävirran vastuut (esimerkkejä)	Alavirran vastuut (esimerkkejä)
MSP – pilvialusta – säännelty asiakas	Sertifioinnit, häiriöilmoitukset, segmentointi, käyttölokit	Hyväksynnät, tietosuojatehtävät, asiakasturvallisuusviestintä
MSP – SaaS-tietoturvatyökalu – sekalaiset asiakasohjelmat	Turvallinen integrointi, roolien suunnittelu, valvonta, toimittajan arviointi	Asiakkaan tietoisuus työkalun laajuudesta, suostumus tarvittaessa
MSP – vertais-MSP (yhteishallittu) – asiakas	Rajojen määrittely, yhteinen tapahtumien käsittely, jaettu käyttöoikeus	Asiakas ymmärtää tehtävien jaon ja etenemispolut

Kuten taulukosta käy ilmi, vastuut vaihtelevat merkittävästi esimerkiksi hyperskaalausskenaarion ja yhteisesti hallinnoidun MSP-järjestelyn välillä. Käytännössä voit aloittaa kartoittamalla nykyiset suhteesi johonkin näistä malleista, vahvistamalla, mitkä tehtävät kuuluvat mihin, ja sitten standardoimalla sopimuslausekkeet ja sisäiset runbookisi näiden mallien mukaisesti.

Ylävirran kontrollien suunnittelu toimittajille ja alihankkijoille

Ylävirran kontrollit määrittelevät, miten valitset, otat käyttöön, valvot ja poistut toimittajista ja alustoista, joihin luotat. Yksinkertainen ja toistettava elinkaari muuttaa toimittajien luottamuksen oletuksesta riskinarviointien, sopimusten ja konfiguroinnin tukemaksi todisteeksi. Liite A.5.21 edellyttää, että elinkaari on oikeassa suhteessa riskiin ja sitä sovelletaan johdonmukaisesti tärkeimpiin toimittajiin.

Hyvä alkuvaiheen suunnittelu muuttaa luottamuksen epävirallisesta arviosta dokumentoiduksi päätökseksi. Tämä tarkoittaa sitä, että ymmärrät, mitä kukin toimittaja tekee puolestasi, mitä riskejä saat, mitä valvontatoimia he käyttävät ja mitkä sinun on itse huolehdittava. Riskiperusteinen elinkaari tekee tästä hallittavaa ja antaa tarkastajille varmuuden siitä, ettet kohtele toimittajia mustana laatikkona.

Toimittajan elinkaaren rakentaminen, jonka auditoijat tunnistavat

Tilintarkastajat etsivät yleensä selkeää, riskiperusteista elinkaarta kriittisille toimittajille: miten arvioit toimittajan ennen käyttöä, miten sisällytät kontrollit niiden käyttöönoton yhteydessä, miten ylläpidät valvontaa ja miten lopetat sopimuksen turvallisesti. Jos pystyt osoittamaan nämä vaiheet ja niiden taustalla olevat todisteet, liitteen A.5.21 mukainen kerroksesi tuntuu uskottavalta ja täydelliseltä. SANSin kaltaisten instituutioiden toimittajariskiohjeistus kuvaa riskiperusteisia toimittajien elinkaaria – jotka kattavat valinnan, perehdytyksen, jatkuvan valvonnan ja lopetuksen – kypsän kolmannen osapuolen tietoturvan hallinnan tunnusmerkiksi (SANS:n toimittajariskien raportti).

Tietoturvan tila 2025 -raportin mukaan suurin osa organisaatioista on jo vahvistanut kolmansien osapuolten riskienhallintaa ja aikoo investoida siihen edelleen.

Käytännönläheisessä toimitusketjun alkupään elinkaaressa on neljä vaihetta: due diligence -tarkastus ennen sitoutumista, perehdytys, normaalin liiketoiminnan valvonta ja poistuminen. Määrittele kullekin toimittajatasolle odotukset ja mitä artefakteja tulisi olla olemassa todistamaan, että nämä toimet tapahtuivat.

Vaihe 1: Suorita riskiperusteinen due diligence -tarkastus

Riskiperusteisessa due diligence -tarkastuksessa kerätään riittävästi tietoa toimittajan tietoturvatilanteen ja sen vastaavuuden ymmärtämiseksi tarpeidesi kanssa. Tähän sisältyvät tyypillisesti riippumattomat sertifioinnit, korkean tason tietoturvalausunnot, testausyhteenvedot, roolit henkilötietojen käsittelyssä ja tiedot alihankkijoista. Tuloksena tulisi olla täytetty arviointiraportti, jossa selitetään, miksi toimittaja on hyväksyttävä valitulla tasolla.

Vaihe 2: Konkreettisten teknisten ja sopimusteknisten valvontatoimien käyttöönotto

Perehdytys muuttaa arvioinnin konkreettisiksi kontrolleiksi. Kriittisellä alustalla tämä voi sisältää vahvan todennuksen määrittämisen, järjestelmänvalvojan roolien rajoittamisen, lokien tallentamisen käyttöönoton ja integroinnin sekä tapausten ilmoitusaikataulujen ja yhteyshenkilöiden sopimisen. Yksinkertainen perehdytyslista auttaa varmistamaan, että näitä vaiheita ei unohdeta ja että jokaisesta on selkeä vastuuhenkilö.

Vaihe 3: Säilytä normaali valvonta

Tavanomaisen valvonnan on oltava kevyttä mutta todellista. Vaikutukseltaan suurten toimittajien kohdalla on asetettava tarkastustaajuudet sen varmistamiseksi, että sertifikaatit ovat voimassa, tietoturvasitoumukset ovat voimassa eikä merkittäviä muutoksia ole tapahtunut ilman lupaasi. Alemmilla tasoilla tarkastuksia voivat käynnistää tapahtumat, kuten palvelumuutokset, uudet tietovirrat tai häiriöt. Näiden tarkastusten tiedot, vaikka ne olisivat lyhyitäkin, osoittavat, että valvonta on aktiivista eikä oletettua.

Vaihe 4: Poistu turvallisesti ja päivitä toimitusketjukarttasi

Toimittajasuhteen lopettaminen usein unohdetaan, mutta se on kriittisen tärkeää. Kun lopetat toimittajan käytön tai vaihdat uudelle alustalle, käyttöoikeuksien peruuttamiseksi, tietojen palauttamiseksi tai turvalliseksi poistamiseksi sekä dokumentaation päivittämiseksi tulisi olla määritelty prosessi, jotta toimitusketjukarttasi pysyy ajan tasalla. Lyhyt poistumistarkistuslista ja päivitetty rekisterimerkintä osoittavat, että olet päättänyt suhteen hallitusti.

Tilintarkastajat eivät odota täydellisyyttä, mutta he odottavat näkevänsä, että tällainen elinkaari on olemassa, se on riskiperusteinen ja sitä noudatetaan käytännössä kriittisten toimittajien osalta.

Yksikään toimittaja ei ole täydellinen, eikä liite A.5.21 edellytä täydellisyyttä. Se edellyttää, että teet tietoon perustuvia, dokumentoituja päätöksiä perimistäsi riskeistä ja soveltamistasi kompensoivista kontrolleista sekä pystyt selittämään nämä päätökset tilintarkastajille ja asiakkaille.

Kaikki toimittajat eivät täytä kaikkia ihanteellisia suojatoimia, eikä kaikkien toimittajan tarvitsekaan. Tärkeää on kykysi selittää, miksi suhde on hyväksyttävä ottaen huomioon sen mukanaan tuomat riskit. Porrastaminen auttaa, mutta sinun on myös selvennettävä, milloin olet tyytyväinen perimään toimittajan oman tietoturvakehyksen suojatoimet ja milloin haluat mieluummin korvaavia toimenpiteitä.

Jos esimerkiksi suurella pilvipalveluntarjoajalla on laajalti tunnustettuja sertifikaatteja ja se noudattaa vahvaa tietoturvastandardia, on yleensä järkevää luottaa niihin monien taustalla olevien kontrollien osalta, edellyttäen, että hallitset kokoonpanoasi turvallisesti. Sitä vastoin pienemmällä erikoisalustalla, jolla on vähemmän muodollinen varmuus, voit päättää rajoittaa sen laajuutta, vaatia erityisiä sopimusvelvoitteita tai lisätä omaa valvontaa ja testausta.

Häiriötilanteiden käsittely ansaitsee erityistä huomiota. Ydinalustoilla tulisi olla selkeät sitoumukset siitä, kuinka nopeasti tietoturvaongelmasta ilmoitetaan, mitä tietoja vastaanotetaan ja miten reagoidaan asiakkaisiin. Nämä odotukset on parasta kirjata sopimuksiin tai palvelusopimuksiin sen sijaan, että ne jätettäisiin epäviralliseksi ymmärrykseksi.

Näiden arvioiden dokumentointi riskirekisteriin ja soveltamislausuntoon osoittaa tilintarkastajille, että liitettä A.5.21 sovelletaan harkitusti, ei automaattisesti. Soveltamislausunto on yksinkertaisesti virallinen luettelo liitteen A mukaisista kontrolleista, joissa selität, mitkä niistä soveltuvat, miten ja miksi.

Ota käyttöön, laajenna ja skaalaa vaatimustenmukaisuus ilman sotkua. Io antaa sinulle joustavuutta ja luottamusta kasvaa turvallisesti.

Varaa esittelysi

Asiakkaiden ja heidän velvoitteidensa mukaisten loppupään kontrollien suunnittelu

Alavirran valvonta määrittelee, miten jaat vastuun asiakkaiden kanssa ja mitä odotat heiltä palveluiden turvallisuuden varmistamiseksi. Hallittujen palveluiden tarjoajien kohdalla selkeät alavirran valvontamekanismit vähentävät riskiä, että heitä syytetään asiakkaaseen liittyvistä riskeistä, ja osoittavat sääntelyviranomaisille, että olet asettanut asianmukaiset ja dokumentoidut odotukset. Liite A.5.21 korostaa tarvetta tehdä näistä odotuksista selkeitä, täytäntöönpanokelpoisia ja näyttöön perustuvia.

Käytännössä alavirran valvonta tarkoittaa rajojen asettamista ja sen varmistamista, että kaikki ymmärtävät ne. Määrittelet, mitä teet oletusarvoisesti, mitä asiakkaiden on tehtävä ja miten osoitat, että molemmat osapuolet täyttävät velvollisuutensa. Kun tämä tehdään hyvin, keskustelut vaaratilanteista, uusista vaatimuksista tai lisäpalveluista alkavat yhteisymmärryksestä sen sijaan, että syntyisi erimielisyyttä siitä, kuka oli vastuussa.

Palvelukohtaisten jaetun vastuun mallien suunnittelu

Hyödyllinen jaetun vastuun malli kertoo asiakkaille selkeästi, mitkä osat tietoturvasta omistat ja mitkä osat he omistavat tietyn palvelun osalta. Eri palveluperheillä on erilaiset jaottelut, joten jokainen tarvitsee oman yksinkertaisen mallinsa, joka heijastaa palvelun todellista suunnittelua. Tässä yhteydessä jaetun vastuun malli on yksinkertaisesti selkeä kuvaus siitä, miten tietoturvatehtävät jaetaan sinun ja asiakkaan välillä.

Rakenna jokaiselle palveluperheelle jaetun vastuun malli, joka vastaa kolmeen kysymykseen:

Mitä konfigurointi- ja valvontaominaisuuksia tarjoatte oletuksena?
Mitä asiakkaan on tehtävä, jotta se olisi tehokasta?
Miten todistat, että molemmat osapuolet tekevät oman osansa?

Esimerkiksi hallitun Microsoft 365 -palvelun osalta vastuisiisi voi kuulua ehdollisten käyttöoikeuskäytäntöjen määrittäminen, lokinkirjauksen käyttöönotto ja keskeisten hälytysten valvonta. Asiakkaan vastuisiin voi kuulua käyttäjätietojen paikkansapitävyys, hyväksyttävän käytön käytäntöjen valvonta ja nopea reagointi tietoturvailmoituksiin. Mallin todentaminen voi sisältää säännöllisiä määritysraportteja ja dokumentoituja asiakashyväksyntöjä.

Näiden mallien tulisi olla kirjoitettu ymmärrettävällä kielellä, niitä tulisi käyttää uudelleen sopimuksissa ja tarjouksissa, ja niitä tulisi tukea sisäisillä käsikirjoilla, jotka näyttävät tiimeillesi, miten heidän puolensa sopimuksesta täytetään. Kun asiakkaat ymmärtävät mallin alusta alkaen, myöhemmät keskustelut tietoturvapoikkeamista tai lisävelvoitteista perustuvat tähän yhteiseen ymmärrykseen pikemminkin kuin tilapäisiin odotuksiin.

Asiakasvelvoitteiden asettaminen ja noudattamatta jättämiseen puuttuminen

Asiakasvelvoitteet kuvaavat, mitä asiakkaiden on tehtävä palvelujesi tehokkuuden varmistamiseksi ja oman riskinsä pitämiseksi hyväksyttävissä rajoissa. Liite A.5.21 edellyttää, että asetat nämä velvoitteet selkeästi, seuraat niitä mahdollisuuksien mukaan ja päätät etukäteen, miten käsittelet puutteet.

Alavirran valvontaan sisältyy usein velvoitteita, kuten:

Tuettujen käyttöjärjestelmien ylläpito.
Varmista, että henkilöstö suorittaa turvallisuustietoisuuskoulutuksen.
Monivaiheisen todennuksen käyttöönotto heidän omissa järjestelmissään.
Ilmoittamalla sinulle viipymättä olennaisista muutoksista heidän ympäristössään.

Näiden velvoitteiden tulisi olla palvelun ja riskiprofiilin mukaisia, kirjattuina sopimuksiin tai turvallisuuslistoihin ja niitä tulisi tukea yksinkertaisilla mekanismeilla näytön keräämiseksi. Näihin voivat kuulua säännölliset todentamiset, tekniset tarkastukset, joissa on näkyvyyttä, tai yhteisten arviointien tulokset.

Yhtä tärkeää on päättää etukäteen, miten toimitaan vaatimustenvastaisuuden varalta. Joitakin puutteita voidaan lieventää; toiset voivat johtaa poikkeuksiin, lisämaksuihin tai äärimmäisissä tapauksissa palvelun tarjoamisen epäämiseen.

Vaihe 1: Määrittele, miten vaatimustenvastaisuus tunnistetaan

Päätä, mitkä velvoitteet voit tarkistaa teknisesti ja mitkä perustuvat asiakastodistuksiin tai arviointikokouksiin. Kirjaa tarkastukset prosesseihisi tai työkaluihisi, jotta vaatimustenvastaisuudet ovat näkyvissä.

Vaihe 2: Päätä, kuka voi myöntää ja hyväksyä poikkeuksia

Dokumentoi, mitkä roolit voivat hyväksyä tilapäisiä poikkeuksia, millä ehdoilla ja kuinka pitkäksi aikaa. Näin vältetään hetkelliset kompromissit, joista myöhemmin tulee pysyviä.

Vaihe 3: Kirjaa ja tarkastele jäännösriskiä

Varmista, että poikkeukset ja noudattamatta jättämiset kirjataan riskirekisteriisi ja että ne tarkistetaan asianmukaisissa hallintofoorumeissa. Tämä osoittaa, että hallitset jäännösriskiä etkä jätä sitä huomiotta.

Selkeät toimitusketjun loppupään mallit ja velvoitteet ovat houkuttelevia kokeneemmille asiakkaille. Ne osoittavat, että otat heidän riskinsä vakavasti ja olet valmis asettamaan ja pitämään kiinni järkevistä rajoista sen sijaan, että suostuisit epämääräisiin ja täytäntöönpanokelvottomiin lupauksiin.

Toimitusketjun hallinnan hallinto, roolit ja elinkaari

Toimitusketjun turvallisuus skaalautuu vain, kun joku selvästi kantaa siitä vastuun ja muu organisaatio ymmärtää oman osansa. Liite A.5.21 tulee kestäväksi, kun se on integroitu hallintoon määritellyillä rooleilla, vastuilla ja arviointirytmeillä sen sijaan, että se jätettäisiin turvallisuuden epäviralliseksi sivutehtäväksi. Tehokas hallinto ei niinkään tarkoita uusien kokousten luomista vaan enemmän parempien kysymysten esittämistä jo järjestetyissä kokouksissa.

Jos toimitusketjun turvallisuutta käsitellään "jonkun ongelmana" ilman selkeyttä, se ajautuu sivuraiteille. On päätettävä, kuka on vastuussa valvonnasta, kuka antaa palautetta, kuka suorittaa tiettyjä tehtäviä ja kuinka usein suorituskykyä tarkastellaan. Hyvä hallintotapa tarkoittaa selkeitä päätöksiä ja säännöllistä palautetta, ei useampia kokouksia.

Tehokas toimitusketjun hallinta tarkoittaa parempien kysymysten esittämistä olemassa olevissa kokouksissa.

Omistajuuden ja RACI:n määrittäminen koko yritykselle

Nimetty vastuunhaltija antaa liitteelle A.5.21 selkeän aseman, mutta menestys riippuu koordinoidusta työstä hankinnan, toiminnan, lakiasioiden ja asiakkuuksien hallinnan välillä. Yksinkertainen RACI-malli tekee selväksi, kuka tekee mitä, kuka hyväksyy ja kenen on pysyttävä ajan tasalla toimittaja- tai asiakasriskien muuttuessa.

Käytännöllinen lähtökohta on nimetä liitteelle A.5.21 yksi valvonnan vastuuhenkilö, joka on usein tietoturvajohtaja tai virtuaalinen tietoturvajohtaja. Tämä henkilö on vastuussa valvonnan suunnittelusta ja toiminnasta, mutta hän ei voi toteuttaa sitä yksin. Hankinnalla, lakiosastolla, operatiivisella toiminnalla ja asiakkuuksien hallinnalla on kaikilla omat roolinsa.

Yksinkertainen RACI-matriisi (vastuullinen, tilivelvollisuus, konsultointi ja tieto) auttaa. Esimerkiksi uuden Tier 1 -toimittajan perehdyttämisessä:

Hankintayksikkö on vastuussa siitä, että sovitut turvallisuuslausekkeet sisältyvät sopimukseen.
Tietoturvapäällikkö on vastuussa toimittajan riskinarvioinnin ja -tason hyväksymisestä.
Lakiasioihin liittyviä neuvoja tarjotaan monimutkaisista ehdoista, poikkeuksista ja vastuista.
Toiminnot ja asiakkuuksien hallinta ovat tietoisia velvoitteista, jotka vaikuttavat heidän palveluiden tarjoamiseensa.

Kun tämä jakauma on selkeä, kollegat eivät enää pidä liitettä A.5.21 "ISO-henkilön ongelmana" ja alkavat ymmärtää oman osuutensa sen ratkaisemisessa.

Toimintoihin sopivien hallintorytmien valitseminen

Hallinto toimii parhaiten, kun toimitusketjuun liittyvät kysymykset sisällytetään jo ennestään tärkeisiin kokouksiin, kuten riskikomiteoihin, johdon katselmuksiin ja palvelukatselmuksiin. Liite A.5.21 ei vaadi uutta byrokratiaa; se edellyttää, että esität oikeat kysymykset toimittajista ja asiakkaista oikeaan aikaan ja kirjaat vastaukset.

Kontrollit pysyvät todennäköisemmin voimassa, kun ne noudattavat organisaation jo ennestään noudattamia rytmejä. Toimitusketjun turvallisuuden kannalta tämä voi tarkoittaa:

Sisällytetään keskeisiin toimittaja- ja asiakasriskeihin liittyviä aiheita pysyviksi asialistan kohtiksi olemassa olevissa riski- tai palvelutarkastuslautakunnissa.
Kriittisten toimittajien ja riskialttiiden asiakkaiden säännöllisten arviointien aikatauluttaminen sopimussyklien tai merkittävien muutosten mukaisesti.
Toimitusketjuun liittyvien vaaratilanteiden ja läheltä piti -tilanteiden tarkastelu vaaratilanteiden jälkeisissä tarkasteluissa ja opittujen kokemusten hyödyntäminen toimittajien ja asiakkaiden hallinnassa.

Vältä kokonaan uusien komiteoiden luomista, ellet tarvitse niitä; sen sijaan sisällytä liite A.5.21 vakiintuneisiin hallintofoorumeihin. Esimerkiksi ISO 27001 -standardin mukaisessa johdon tarkastelussasi voidaan nimenomaisesti käsitellä toimitusketjun suorituskyvyn mittareita vasten, kuten kriittisten toimittajien lukumäärää, joilla ei ole ajantasaisia arviointeja, toimittajiin liittyvien häiriöiden esiintymistiheyttä tai häiriöiden ilmoitusten ajantasaisuutta.

Hallinnan tulisi ulottua myös vähemmän näkyviin suhteisiin, kuten työajan ulkopuoliseen valvonnaen käytettyihin alihankkijoihin tai white-label-palveluntarjoajiin, jotka toimittavat palveluja brändisi alla. Toimitusketjun kuva on epätäydellinen ilman heitä, ja näihin osapuoliin liittyvät vaaratilanteet voivat olla aivan yhtä vahingollisia. Sen varmistaminen, että he ovat riskinarvioinnin, sopimusvalvonnan ja valvonnan piirissä, on osa uskottavaa liitteen A.5.21 täytäntöönpanoa.

ISMS.online tukee yli 100 standardia ja sääntöä, mikä tarjoaa sinulle yhden alustan kaikkiin vaatimustenmukaisuustarpeisiisi.

Varaa esittelysi

A.5.19–A.5.22:n integrointi riski-, toimittaja- ja muutosprosesseihin

Liitteet A.5.19–A.5.22 toimivat parhaiten, kun ne on nidottu prosesseihin, joita jo käytät riskien, toimittajien, muutosten ja häiriöiden hallintaan. Sen sijaan, että ne olisivat erillisiä "ISO-tehtäviä", niiden tulisi näkyä riskirekisterissäsi, hankintaprosessissasi, muutoshallinnassasi ja häiriöiden jälkeisissä arvioinneissa, jotta toimitusketjun ajattelusta tulee osa päivittäistä työtä. Tämä integrointi muuttaa politiikkalausekkeet johdonmukaiseksi toiminnaksi.

Kaksi kolmasosaa organisaatioista vuoden 2025 tietoturvallisuuden tilaa koskevassa kyselyssä sanoi, että sääntelymuutosten nopeus ja määrä vaikeuttavat vaatimustenmukaisuuden ylläpitämistä.

Käytäntöjen ja mallien suunnittelu on välttämätöntä, mutta ei yksin riitä. Toimitusketjun kontrollit toimivat vain, jos ne on sisällytetty lomakkeisiin, tiketteihin ja työnkulkuihin, joita ihmiset jo käyttävät muutosten pyytämiseen, uusien työkalujen käyttöönottoon, riskien arviointiin ja poikkeamiin reagoimiseen. Liitteet A.5.19–A.5.22 ovat tehokkaimpia, kun ne heijastuvat riskien kirjaamisessa, toimittajia koskevien päätösten tekemisessä, muutosten hyväksymisessä ja poikkeamista oppimisessa.

Toimitusketjuajattelun sisällyttäminen jokapäiväisiin työnkulkuihin

Ensimmäinen askel on tehdä ICT-toimitusketjun riskistä näkyvää muiden riskien rinnalla. Tämä tarkoittaa kriittisille palveluille ja toimittajille tarkoitettujen riskimerkintöjen luomista ja näiden riskien käsittelytapojen kirjaamista. Kun tämä on tehty, voit lisätä pieniä, pakollisia tarkistuspisteitä tiimisi jo noudattamiin työnkulkuihin, jotta toimittajia ja muutoksia koskevat päätökset heijastavat automaattisesti liitteen A odotuksia.

Aloita varmistamalla, että keskitetty riskirekisterisi tallentaa nimenomaisesti ICT-toimitusketjun riskit. Jokaiselle merkittävälle palvelulle ja kriittiselle toimittajalle tulisi olla riskimerkinnät, jotka heijastavat heidän epäonnistumisensa tai vaarantumisensa mahdollista vaikutusta sekä valittuja hoitokeinoja. Tämä asettaa toimitusketjun riskin muiden haavoittuvuuksien rinnalle ja auttaa johtoa ymmärtämään kompromisseja.

Seuraavaksi integroi toimitusketjun tarkistuspisteet olemassa oleviin työnkulkuihin:

Hankintaprosesseihin tulisi sisältyä kehotteita sen tarkistamiseksi, kuuluuko ehdotettu toimittaja tiettyyn riskiluokkaan, onko due diligence -tarkastus suoritettu ja sisältävätkö sopimusmallit vaaditut turvallisuuslausekkeet.
Muutospyyntöjen, jotka ottavat käyttöön tai korvaavat merkittäviä työkaluja tai alihankkijoita, tulisi automaattisesti käynnistää sekä alku- että loppupään vaikutusten tarkastelu, ei pelkästään teknisen yhteensopivuuden tarkastelu.
Uusien asiakkaiden palvelusuunnittelun tai perehdytysprosessien tulisi sisältää vaiheet asianmukaisen jaetun vastuun mallin soveltamiseksi ja sen varmistamiseksi, että loppupään velvoitteet dokumentoidaan ja hyväksytään.

Näitä kehotteita voidaan usein lisätä lomakkeisiin ja tikettipohjiin minimaalisella kitkalla, kunhan ne ovat pakollisia tärkeissä tilanteissa ja vastaukset tallennetaan keskitetysti, jotta ne syötetään takaisin tietoturvanhallintajärjestelmän tietueisiin.

Suorituskyvyn mittaaminen ja poikkeamista oppiminen

Et voi parantaa sitä, mitä et näe. Liitteestä A.5.21 tulee paljon arvokkaampi, kun seuraat toimitusketjun valvonnan toimivuutta ja hyödynnät poikkeamista saatuja kokemuksia tasoillasi, malleissasi ja toimintaohjeissasi. Tavoitteena ei ole ajaa kaikkia lukuja nollaan, vaan ymmärtää, missä toimitusketjusi suurimmat riskit todella sijaitsevat, ja osoittaa, että hallitset niitä.

Kun kontrollit toimivat, tarvitset palautetta niiden parantamiseksi. Hyödyllisiä toimenpiteitä voivat olla:

Niiden kriittisten toimittajien osuus, joilla on ajantasaiset riskinarvioinnit ja dokumentoidut turvallisuussitoumukset.
Niiden tapausten lukumäärä ja vakavuus, joissa perimmäinen syy liittyi ylä- tai alavirran suhteeseen.
Aika, joka kuluu asiaankuuluvien toimittajien häiriöiden ilmoittamiseen ja viestintään niiden asiakkaiden kanssa, joihin ne ovat vaikuttaneet.
Asiakkaiden keskeisten alavirran velvoitteiden noudattamatta jättämisen määrä ja poikkeusten myöntämisen tiheys.

Häiriöiden sattuessa perussyyanalyysin tulisi tarkoituksella erottaa toisistaan ylävirran epäonnistumiset, sisäiset ongelmat ja alavirran heikkoudet. Tämä erottelu antaa tietoa siitä, missä kohtaa sinun on tiukennettava odotuksiasi, parannettava omia käytäntöjäsi tai mukautettava asiakasvelvoitteitasi. Näiden tietojen syöttäminen takaisin toimittajien porrastukseen, sopimusmalleihin ja käsikirjoihin tekee Annex A.5.21 -toteutuksestasi aidosti iteratiivisen, ei staattisen.

Erityinen tietoturvallisuuden hallintajärjestelmä (ISMS) voi auttaa sinua yhdistämään toimittajat, palvelut, asiakkaat, riskit ja kontrollit yhteen paikkaan, jotta yksittäinen muutos tai tapahtuma voidaan jäljittää kaikissa sen vaikutuspiirissä olevissa suhteissa. Vaikka et olisikaan valmis ottamaan tällaista alustaa käyttöön välittömästi, prosessiesi suunnittelu siten, että tarvittavat tiedot voidaan myöhemmin tallentaa keskitetysti, on käytännöllinen askel kohti integroidumpaa tietoturvallisuuden hallintajärjestelmää.

Varaa esittely ISMS.onlinesta jo tänään

ISMS.online voi auttaa sinua siirtämään liitteen A.5.21 hajanaisista toimittajaluetteloista ja sopimuslausekkeista yhdeksi eläväksi kuvaksi ICT-toimitusketjustasi, kontrolleistasi ja todisteistasi. Korvaamalla laskentataulukot, sähköpostipolut ja erilliset asiakirjat yhdellä yhdistetyllä ympäristöllä voit nähdä ylä- ja alavirran suhteet selkeämmin, jäljittää vastuut ja vastata asiakkaiden ja tilintarkastajien vaikeisiin kysymyksiin luottavaisemmin.

Jos epäilet, että monimutkaiseen asiakaskyselyyn tai ISO 27001:2022 -auditointiin vastaaminen aiheuttaisi silti ongelmia, se on merkki siitä, että kannattaa tutkia jäsennellympää lähestymistapaa. Kun näet ylä- ja alavirran suhteet selkeästi kartoitettuina ja vastuut ja riskit yhdellä silmäyksellä näkyvissä, se antaa sinulle varmemman kuvan asiakkaille, tilintarkastajille ja johdolle.

Kuinka pilotoida A.5.21-vaatimusta toimitusketjusi yhdessä osassa

Kohdennettu pilottihanke on yksinkertaisin tapa nähdä, miltä liite A.5.21 näyttää, kun se on täysin integroitu tietoturvan hallintajärjestelmään. Sen sijaan, että yrittäisit mallintaa koko maailmaasi kerralla, keskityt pieneen, edustavaan osaan toimitusketjuasi ja testaat, vähentävätkö rakenne ja työkalut todella vaivaa ja epävarmuutta.

Käytännön pilottihanke voisi alkaa yhdellä kriittisellä alkupään alustalla ja yhdellä korkean riskin asiakkaalla. Voit tuoda nämä suhteet ISMS.online-järjestelmään, yhdistää ne liitteisiin A.5.19–A.5.22 ja tallentaa keskeiset tiedot: toimittajien riskinarvioinnit, jaetun vastuun mallit, asiakasvelvoitteet ja seurantatodisteet. Tämän rajatun laajuuden puitteissa voit nähdä, vähentääkö alusta merkityksellisesti työtä, selventääkö omistajuutta ja parantaako se valmiuttasi vastata tilintarkastajien ja asiakkaiden kysymyksiin.

Pitämällä pilottihankkeen pienenä pysyt laajuuden hallinnassa ja vältät jo ennestään kiireisten tiimien ylikuormittamisen. Samalla annat itsellesi konkreettisia esimerkkejä – täytetyn riskirekisterimerkinnän, dokumentoidun toimittajan elinkaaren ja jaetun vastuun matriisin – joita voit näyttää kollegoille ja johdolle keskusteltaessa lähestymistavan skaalaamisesta.

Mitä ottaa mukaan ISMS.online-keskusteluun

Saat ISMS.online-keskustelusta eniten irti, jos sinulla on yksinkertainen kuva nykyisestä toimitusketjustasi ja sen haasteista. Pieni valmistelu helpottaa hahmottamaan, miten alusta voisi tukea juuri sinun tilannettasi ja sopiiko se organisaatiollesi.

Hyödyllisiä syötteitä ovat tyypillisesti:

Lista kriittisimmistä ICT-toimittajistasi ja heidän tukemistaan palveluista.
Lyhyt lista vaikuttavista asiakkaista, erityisesti säännellyillä aloilla toimivista.
Kaikki olemassa olevat asiakirjat, jotka kuvaavat jaettuja vastuita, asiakasvelvoitteita tai toimittajien odotuksia.
Esimerkkejä viimeaikaisista toimittajiin tai asiakkaisiin liittyvistä vaikeista hallinnoista.

Näiden syötteiden avulla ISMS.online-tiimi voi käydä läpi, miltä todelliset suhteesi näyttäisivät alustan sisällä ja miten liitteet A.5.19–A.5.22 ilmenisivät käytännössä. Tavoitteena ei ole ehdottaa yleistä ratkaisua, vaan osoittaa omien esimerkkien avulla, kuinka linkitetty ISMS voisi yksinkertaistaa liitettä A.5.21 ja parantaa toimitusketjusi tasoa.

Jos tunnistat oman organisaatiosi näissä tilanteissa ja haluat testata integroidumpaa lähestymistapaa, ISMS.online on valmis tutkimaan kanssasi kohdennettua pilottihanketta, jossa käytät oikeita toimittajiasi ja asiakkaitasi nähdäksesi, onko integroitu ISMS oikea seuraava askel hallinnoidulle tuote- ja palvelusuunnitelmallesi.

Varaa demo

Usein Kysytyt Kysymykset

Miten ISO 27001:2022 -standardin liite A.5.21 muuttaa tapaa, jolla hallinnoidun palveluntarjoajan (MSP) tulisi ajatella ICT-toimitusketjuaan?

Liite A.5.21 edellyttää, että johdat ICT-toimitusketjuasi yhtenä hallittuna järjestelmänä pilvialustalta asiakkaalle, ei joukkona irrallisia toimittajia, työkaluja ja sopimuksia. Hallitun palveluntarjoajan kannalta tämä tarkoittaa, että sinulla on oltava reaaliaikainen ja perusteltavissa oleva kuva siitä, miten ylävirran palveluntarjoajat, omat palvelusi ja alavirran asiakkaat ovat sidoksissa toisiinsa ja miten hallitset riskejä koko ketjussa.

Mitä ”kokonaisvaltainen tieto- ja viestintätekniikan toimitusketju” oikeastaan tarkoittaa MSP:lle?

Kokonaisvaltainen lähestymistapa tarkoittaa, että voit aloittaa yhdestä palvelusta ja jäljittää:

Joka ICT-tuotteet ja -palvelut johon luotat sen toimittamisessa.
Kuinka sinun omat alustat ja prosessit istua keskellä.
Joka asiakkaat tai asiakassegmentit niihin vaikuttaa, jos jokin menee rikki.

Sen sijaan, että lausekkeella ”käytämme toimittajaa X ja palvelemme asiakasta Y”, liitteessä A.5.21 oletetaan, että ymmärrät ja hallitset koko polkua: pilvi/alustat → MSP-työkalut ja -prosessit → asiakasympäristötJos ydinalusta kaatuu tai vaarantuu, sinun pitäisi jo tietää, mitkä palvelut ja vuokralaiset altistuvat ja mitä aiot tehdä asialle.

Käytännössä se tarkoittaa, että voit:

Osoita toimittajarekisteriin, joka yhdistää ICT-toimittajat palveluihin ja riskiluokkiin.
Selitä selkeästi, kuka tekee mitä (sinä, toimittaja, asiakas) kunkin palvelutyypin osalta.
Osoita, että tämä kuva pysyy ajan tasalla, kun palvelut, toimittajat tai määräykset muuttuvat.

Jos pystyt opastamaan tilintarkastajaa kyseisen kerroksen läpi käyttämällä jokapäiväisiä asiakirjoja kertaluonteisen "tarkastuspaketin" sijaan, käsittelet liitettä A.5.21 osana liiketoimintaasi, mikä on juuri sitä, mitä he etsivät.

Miten liite A.5.21 pohjautuu muihin liitteen A.5 toimittajan valvontamekanismeihin hallittujen palvelujen tarjoajalle?

Liite A.5.21 ottaa yleiset toimittajateemat kohdista A.5.19, A.5.20 ja A.5.22 ja soveltaa niitä erityisesti hallittujen palveluiden perustana olevaan ICT-ympäristöön. Liite ei niinkään käsittele uusien prosessien keksimistä vaan enemmän toimittajien valinnan, sopimusten, valvonnan ja muutosten yhdistämistä yhdeksi yhtenäiseksi lähestymistavaksi ICT-tuotteille ja -palveluille.

Miten liitteen A.5 mukaiset toimittajan kontrollit sopivat yhteen MSP:n ICT-toimitusketjussa?

Voit ajatella neljää ohjausobjektia yhtenä työnkulkuna:

A.5.19 – Tietoturva toimittajasuhteissa: Päätä, missä turvallisuus on tärkeää toimittajaverkostossasi ja miten otat sen huomioon valinnoissasi.
A.5.20 – Tietoturvan käsittely toimittajasopimuksissa: Muunna nämä odotukset selkeiksi lausekkeiksi, lisäyksiksi ja palvelukuvauksiksi.
A.5.21 – Tietoturvallisuuden hallinta ICT-toimitusketjussa: Sovelta tätä ajattelutapaa hallinnoitujen palveluidesi alla olevaan ICT-alustojen, työkalujen ja integraatioiden verkostoon.
A.5.22 – Toimittajien palveluiden seuranta, tarkastelu ja muutoshallinta: Pidä toimittajariskit ja suorituskyky ajan tasalla ja reagoi poikkeamiin ja muutoksiin.

MSP:lle tämä tarkoittaa yleensä kolmea näkyvää ominaisuutta:

A yhdistetty rekisteri jossa ICT-toimittajat on sidottu palveluihin, riskiluokituksiin ja sopimusvelvoitteisiin.
A yhtenäinen kuvio siitä, miten perehdyt, valvot ja lopetat ICT-toimittajien myynnin, sen sijaan, että tekisit kertaluonteisia päätöksiä sähköpostitse.
A jäljitettävä linkki näistä toiminnoista asiakkaille annettaviin lupauksiin ja sisäiseen riskirekisteriisi.

ISMS.online-alustan kaltaisen alustan käyttö helpottaa näiden pisteiden yhdistämistä, koska voit tallentaa toimittajat, sopimukset, riskit ja liitteiden A.5.19–A.5.22 mukaiset kontrollit yhteen paikkaan. Näin voit osoittaa tilintarkastajille ja asiakkaille, että hallitset ICT-toimitusketjua etkä vain sopimusten arkistokaappia.

Miten MSP:n tulisi suunnitella liitteen A.5.21 vaatimukset täyttävä ICT-toimittajan elinkaari ylävirran puolelle kuormittamatta tiimiä liikaa?

Tehokkain tapa täyttää liitteen A.5.21 vaatimukset alkupäässä on määritellä yksi toistettavissa oleva toimittajan elinkaari ja skaalata tarkastusten syvyyttä riskin, ei arvailun, mukaan. Tiimisi tarvitsee oppia vain yksi kaava, ja varaat tiukan due diligence -tarkastuksen niille toimittajille, jotka voivat todella vahingoittaa sinua tai asiakkaitasi.

Millainen on käytännöllinen ja toistettavissa oleva ICT-toimittajan elinkaari hallinnoidulle palveluntarjoajalle (MSP)?

Yksinkertainen nelivaiheinen elinkaari tasapainottaa yleensä vaivannäön ja varmuuden:

Valitse: Luokittele toimittaja vaikuttavuuden perusteella ennen sitoutumista. Alusta, joka käsittelee asiakastietoja tai sijaitsee etähallintapinon keskellä, ansaitsee perusteellisemmat tarkastukset kuin vähäarvoinen sähköyhtiö.
Kyydissä: Muunna odotuksesi konkreettisiksi hallintakeinoiksi. Määritä käyttöoikeudet, lokitiedot, muutosilmoitukset, tukikanavat ja poistumisehdot ennen julkaisua.
toimivat: Tarkastele suorituskykyä ja riskejä järkevällä tahdilla. Kriittisten alustojen osalta aikatauluta vähintään vuosittainen tarkastus sekä tarkastukset tietoturvatiedotteiden, häiriöiden tai merkittävien palvelumuutosten jälkeen.
Exit: Suunnittele, miten poistat tai siirrät tietoja, peruutat käyttöoikeudet, vaihdat riippuvuuksia ja päivität omaa dokumentaatiotasi, kun lähdet toimittajalta tai alennat hänen tasoaan.

Et tarvitse monimutkaisia työkaluja todistaaksesi noudattavasi tätä elinkaarta. Ylläpidetty toimittajarekisteri, lyhyet due diligence -muistiinpanot, yksinkertaiset perehdytyslistat ja perustarkastustiedot antavat jo tilintarkastajille selkeän signaalin siitä, että kohtelet ICT-toimittajia osana tietoturvanhallintajärjestelmääsi.

ISMS.online voi vahvistaa tätä entisestään säilyttämällä toimittajarekisterin, elinkaaritodisteet ja linkitetyt liitteeseen A.5.19–A.5.22 liittyvät kontrollit yhdessä ympäristössä. Tämä auttaa pitämään prosessin kevyenä tiimillesi ja samalla esittelemään selkeän ja johdonmukaisen mallin asiakkaille, tilintarkastajille ja kumppaneille.

Kuinka MSP voi määritellä asiakkaiden kanssa jaetut vastuut loppupäässä siten, että liite A.5.21 on katettu, mutta jokaisesta sopimuksesta ei tule oikeudellista romaania?

Alavirran osalta liite A.5.21 täyttää vaatimukset, kun asiakkaasi näkevät selkokielellä, mitä suojaat oletusarvoisesti, mitä heidän on itse tehtävä ja miten työskentelette yhdessä, jos jokin muuttuu tai menee pieleen. Et tarvitse räätälöityä lakitekstiä jokaista sopimusta varten, mutta tarvitset pienen joukon jaettuja vastuumalleja, jotka tiimisi ymmärtävät ja soveltavat johdonmukaisesti.

Miltä toimiva jaetun vastuun malli näyttää yhteisille merten aluesuunnittelun palveluille?

Käytännöllinen malli on standardoida mallit palveluperheittäin ja pitää rakenne samana joka kerta. Määrittele kullekin perheelle neljä lohkoa:

Palvelun laajuus: Mitä tämä hallinnoitu palvelu kattaa ja mitä se ei kata.
Vastuualueesi: Esimerkiksi peruskonfiguraatio, lokin lokitiedot, varmuuskopiointi, valvonta, haavoittuvuuksien käsittely ja tapausten koordinointi.
Asiakkaan vastuut: Esimerkiksi päätepisteiden tukeminen, monivaiheisen todennuksen valvonta, liittyjien/lähtejien hallinta ja tärkeimmistä muutoksista tiedottaminen.
Jaetut vastuut: Esimerkiksi käyttöoikeustarkastukset, riskialttiiden muutosten hyväksyminen tai tapahtumaviestinnän suorittaminen.

Voit sitten ilmaista nämä mallit useilla tavoilla:

Lyhyt vastuumatriisit tarjouksissa, työmäärissä ja perehdytysasiakirjoissa.
Turvallisuuslisäykset: jotka liittyvät sopimuksiin ilman, että koko ehtoja kirjoitetaan uudelleen.
Sisäiset runbookit: joita tiimisi käyttävät perehdytyksessä, toiminnassa ja tapahtumien käsittelyssä.

Kun asiakas tarvitsee poikkeuksen, dokumentoit poikkeaman eksplisiittisesti sen sijaan, että venyttäisit mallia hiljaa. Kun nämä mallit ja poikkeukset ovat tietoturvanhallintajärjestelmässäsi ja heijastuvat riskirekisteriisi, voit osoittaa, että alavirran riskiä käsitellään tarkoituksella eikä epämuodollisesti. Juuri tätä liite A.5.21 pyrkii testaamaan.

ISMS.online tarjoaa sinulle keskitetyn paikan näiden mallien tallentamiseen ja uudelleenkäyttöön, niiden linkittämiseen tiettyihin palveluihin ja asiakkaisiin sekä sopimustekstien, sisäisten käsikirjojen ja riskimerkintöjen pitämiseen linjassa portfoliosi kasvaessa.

Kuinka MSP voi muuttaa monimutkaisen toimittajien, alustojen ja asiakkaiden verkoston selkeäksi ICT-toimitusketjun riskikartaksi, joka kestää liitteen A.5.21 mukaiset tarkastukset?

Helpoin tapa rakentaa mielekäs toimitusketjun riskikartta on aloittaa siitä, miten palvelusi todellisuudessa toimivat tällä hetkellä, sen sijaan, että aloittaisit staattisesta toimittajaluettelosta. Kun seuraat tietovirtoja ja kontrollipisteitä vasemmalta oikealle, liitteen A.5.21 kannalta tärkeimmät suhteet yleensä paljastuvat.

Millä käytännön vaiheilla luodaan ICT-toimitusketjun kartta, jota tilintarkastajat voivat seurata?

Voit rakentaa kartan kolmessa toisistaan riippumattomassa vaiheessa:

Palvelunäkymä: Listaa hallinnoidut palvelusi (esimerkiksi hallittu Microsoft 365, hallitut päätepisteet, hallittu varmuuskopiointi, yhteishallittu pilvi) ja merkitse muistiin, mistä ylävirran alustoista, työkaluista ja integraatioista kukin on riippuvainen.
Suhdenäkymä: Listaa kunkin palvelun osalta:

Focus-patjan yläjuoksulla Olennaiset ICT-toimittajat ja -alustat.
Focus-patjan myötävirtaan asiakkaat tai asiakasryhmät, jotka kuluttavat kyseistä palvelua.

Riskinäkökulma: Kirjaa jokaiselle vaikuttavalle toimittajalle tai asiakassegmentille erillinen riski, jossa todetaan:

Mikä voisi kohtuudella mennä pieleen (esimerkiksi käyttökatkos, tietomurto, lisenssin muutos).
Miten se vaikuttaisi palveluihin ja asiakkaiden tuloksiin.
Mitkä kontrollit, sopimusehdot ja toimintatavat vähentävät todennäköisyyttä tai vaikutusta.

Monet MSP:t pitävät yksinkertaista kaaviota hyödyllisenä, vaikka sitä ei koskaan näyttäisikään ulospäin: pilvi/alustat → MSP-työkalut ja -prosessit → asiakasympäristöt, väreillä tai kuvakkeilla suhteellisen riskin osoittamiseksi. Tämä kuva auttaa sinua päättämään, mihin panostaa, ja antaa tilintarkastajille ja asiakkaille yksinkertaisen tavan ymmärtää riippuvuutesi.

ISMS.online-ympäristössä voit peilata tätä rakennetta linkittämällä palvelut, toimittajat, asiakkaat ja riskit yhteen ympäristöön. Tämä helpottaa huomattavasti uuden alustan tai asiakkaan lisäämisen kartalle, sen luokittelun ja siihen liittyvien riskien ja vastuiden johdonmukaisen päivittymisen havainnollistamista.

Mitkä jokapäiväiset tiedot vakuuttavat ISO 27001 -auditoijat siitä, että MSP aidosti hallinnoi liitettä A.5.21 sen sijaan, että se vain nimetään dokumentaatiossa?

Tilintarkastajat ovat yleensä kiinnostuneempia siitä, kertovatko päivittäiset kirjanpitosi johdonmukaisen tarinan, kuin siitä, kuinka vaikuttavilta työkalusi näyttävät. Liitteen A.5.21 osalta he haluavat nähdä, että ymmärrät, mistä ICT-toimitusketjun riski tulee, sovellat toistettavissa olevaa käsittelyä ja voit osoittaa tämän käsittelyn luomatta toista erillistä liiketoimintaa, joka on tarkoitettu tilintarkastuspaperille.

Mitkä normaalit artefaktit yleensä täyttävät liitteen A.5.21 vaatimukset MSP:ille ilman rinnakkaisen "auditointiteollisuuden" rakentamista?

Useimmissa hallinnoiduissa suunnitelmissa (MSP) kompakti tietuekokoelma riittää, jos se on täydellinen ja ajan tasalla:

A toimittajarekisteri joka listaa ICT-toimittajat, linkittää ne palveluihin, näyttää niiden riskiluokituksen ja kirjaa viimeisimpien tarkastusten päivämäärät.
Lyhyt due diligence -muistiinpanot korkeamman riskin toimittajille, kuten viittaukset sertifiointeihin, kyselyvastauksiin tai tiiviisiin riskinarviointeihin.
Sopimukset tai turvallisuusliitteet: joissa esitetään turvallisuusodotukset, tietoturvaloukkausten ilmoitussäännöt, tietojenkäsittely ja alihankkijan ehdot.
Seuranta- ja tarkistustiedot: , kuten palvelutarkastuspyyntöjä, toimittajien tarkastusten pöytäkirjoja tai tapahtuman jälkeisiä arviointeja, jotka osoittavat, miten reagoit.
Jaetun vastuun mallit: ja niihin liittyviä lausekkeita asiakassopimuksissa sekä todellisia esimerkkejä siitä, miten toimit, kun kummankaan osapuolen velvoitteita ei täytetä.

Erillisten ”auditointipakettien” rakentamisen sijaan on yleensä tehokkaampaa varmistaa, että normaalit asiakirjat – perehdytyslistat, muutostietueet, runbookit, tapausten ja ongelmien tarkastelut – jättävät automaattisesti jälkeensä auditoijan pyytämät todisteet.

Jos keskität nämä artefaktit ISMS.online-palveluun ja linkität ne nimenomaisesti liitteen A kontrolleihin ja asiaankuuluviin riskeihin, voit vastata auditointikysymyksiin ja asiakaskyselyihin nopeasti suodattamalla ja viemällä tiedot yhdestä paikasta. Ajan myötä tämä vähentää auditointistressiä, lyhentää myyntisyklejä ja auttaa tiimiäsi saamaan tunnustusta hyvin hallitusta ICT-toimitusketjusta sen sijaan, että joka vuosi yritettäisiin koota sama kerros uudelleen alusta alkaen.

Kuinka MSP voi käyttää ISMS.online-järjestelmää liitteen A.5.21 upottamiseen normaaliin toimitusketjun toimintaan sen sijaan, että sitä käsiteltäisiin kertaluonteisena vaatimustenmukaisuusprojektina?

Liitteestä A.5.21 tulee hallittava, kun se on integroitu palveluiden osto-, toimitus- ja arviointitapaasi, eikä sitä käsitellä erillisenä standardina, jota voi "tarkistella". ISMS.online tukee tätä muutosta tarjoamalla yhden ympäristön toimittajien, palveluiden, asiakkaiden, riskien, kontrollien ja todisteiden yhdistämiseen, jotta jokapäiväiset toiminnot pitävät liitteen A.5.21 luonnollisesti hyvässä kunnossa.

Miltä näyttää, kun liite A.5.21 on aidosti otettu käyttöön ISMS.online-palvelussa?

Realistinen malli monille MSP:ille näyttää tältä:

Sinä ylläpidät reaaliaikainen toimittajarekisteri ISMS.online-palvelussa luokittelemalla ICT-toimittajat vaikutuksen mukaan ja linkittämällä kukin tukemiinsa hallittuihin palveluihin ja liitteen A.5.19–A.5.22 mukaisiin kontrolleihin.
Sinä vangitset due diligence, perehdytys, seuranta ja exit-toiminnot normaaleina työtehtävinä, joten liitteeseen A.5.21 tarvitsemasi todisteet kertyvät automaattisesti tiimisi työskennellessä toimittajien kanssa.
Säilytät ja käytät uudelleen jaetun vastuun mallit strukturoituna sisältönä, yhdistämällä ne palveluperheisiin ja asiakasryhmiin, jotta sopimustekstit, runbookit ja riskimerkinnät pysyvät yhdenmukaisina.
Linkität riskit sekä toimitusketjun alkupään toimittajille että loppupään asiakkaille, joten muutos yhdessä ketjun osassa muuttaa välittömästi näkemystäsi toimitusketjun kokonaisaltistuksesta.

Vähäriskisin tapa aloittaa on valita yksi tärkeä palvelu, yksi kriittinen ylävirran alusta ja yksi edustava asiakas, mallintaa ketju päästä päähän ISMS.online-järjestelmässä ja sitten ajaa todellinen muutos tai tapahtuma järjestelmän läpi. Jos tiimisi ja tilintarkastajasi havaitsevat riippuvuudet, selittävät velvoitteet ja keräävät todisteita tästä yhdestä esimerkistä, sinulla on vahva sisäinen peruste laajentaa samaa lähestymistapaa laajempaan ICT-toimitusketjuusi.

Ajan myötä tämä työskentelytapa auttaa yritystäsi näyttämään paitsi "järjestelmien toiminnassa pitävältä", myös jäljitettävän ja hyvin hallitun ICT-toimitusketjun ylläpitäjältä, joka kestää asiakaskyselyt ja ISO 27001 -auditointien ja häiritsee huomattavasti päivittäistä työtäsi. Kun olet valmis näyttämään kerroksen asiakkaalle tai auditoijalle, ISMS.online tarjoaa kaiken tarvitsemasi yhdessä paikassa sen sijaan, että sinun täytyisi koota se paineen alla.

A.5.21 Tietoturvallisuuden hallinta ICT-toimitusketjussa – MSP Upstreamdownstream Control