Monessa yrityksessä NIS2-keskustelu alkaa kysymyksellä SFS-EN ISO 27001 -sertifikaatista. Se on ymmärrettävää, mutta johdon ja prosessinomistajien näkökulmasta väärä lähtökohta. Ensin on selvitettävä, kuuluuko organisaatio velvoitteiden piiriin, mitä palveluja ja resursseja velvoitteet koskevat sekä kenellä on niistä vastuu. Vasta tämän jälkeen voidaan arvioida luotettavasti, mitä nykyinen tietoturvallisuuden hallintajärjestelmä todella kattaa ja mitä Puolan KSC-vaatimusten täyttämisestä vielä puuttuu. Käytännössä juuri tässä ratkaistaan, onko organisaatiolla hallittu järjestelmä vai kallis valmiuden illuusio.
Kallein virhe: sertifikaatin rinnastaminen vaatimustenmukaisuuteen
Suurin alkuvaiheen virhe ei ole SFS-EN ISO 27001 -sertifikaatin puuttuminen vaan oletus siitä, että sertifikaatti ratkaisisi NIS2-direktiivistä ja Puolan KSC-järjestelmää toimeenpanevasta kansallisesta sääntelystä johtuvien velvoitteiden täyttymisen. Johdon kannalta oikea kysymys ei ole ”onko meillä SFS-EN ISO 27001 -sertifikaatti”, vaan ”kuulummeko velvoitteiden piiriin, missä asemassa ja minkä palvelujen, prosessien sekä resurssien osalta”. Vasta organisaation aseman, vaatimusten piiriin kuuluvan toiminnan ja johdon vastuiden selvittämisen jälkeen voidaan arvioida, missä määrin nykyinen järjestelmä tukee vaatimustenmukaisuutta ja missä se vain luo vaikutelman hallinnasta.
Erottelulla on suora vaikutus hankkeen sisältöön ja budjettiin. Sertifikaatti osoittaa, että hallintajärjestelmä täyttää standardin vaatimukset määritellyssä sertifiointilaajuudessa, joka on tavallisesti kuvattu sertifikaatissa ja täsmennetty soveltuvuuslausunnossa. Se ei kuitenkaan korvaa lakisääteisten velvoitteiden analysointia, olennaisten palvelujen tunnistamista, toimittajariippuvuuksien arviointia eikä sen määrittämistä, mitä muodollisia toimia sääntelyn piiriin kuuluvan organisaation on toteutettava. Johdon on siksi erotettava toisistaan kolme käytännössä usein sekoittuvaa kokonaisuutta: hallintajärjestelmä, sääntelyvaatimusten mukaisuus ja operatiivinen valmius toimia poikkeamatilanteen paineessa.
Kalleimmiksi tulevat hankkeet, joissa työ tehdään päinvastaisessa järjestyksessä. Organisaatio järjestää ensin dokumentaation ja valvontatoimet sertifiointiauditointia varten ja havaitsee vasta myöhemmin, että kriittiset prosessit, poikkeamien ilmoitusvelvoitteet, toimittajavaatimukset, johdon vastuut tai toimialakohtaiset vaatimukset jäivät soveltamisalan ulkopuolelle. Tällöin muutaman menettelyohjeen täydentäminen ei riitä. Järjestelmän soveltamisala, päätöksentekoroolit ja reagointimalli on suunniteltava uudelleen.
Operatiivisesti tarkasteltuna sertifikaatin olemassaolon sijasta kannattaa seurata kolmea asiaa: vastaako sertifiointilaajuus kriittisiä palveluja, mitä KSC-soveltamisalaa koskeva itsearviointi osoittaa ja kuinka monta aukkoa menettelyohjeiden sekä todellisen toimintakyvyn välillä on. Luonteva ensimmäinen askel ei siten ole dokumentaation kasvattaminen, vaan sen selvittäminen, kuuluuko organisaatio velvoitteiden piiriin ja mitä muodollisia toimia siltä edellytetään. Tätä työjärjestystä jäsentää myös artikkeli NIS2: itsearviointi ja merkitseminen KSC-luetteloon – mitä tuotantoyrityksen on tehtävä? Juuri tässä vaiheessa ratkaistaan, rakennetaanko järjestelmä todellisten velvoitteiden vai helpon mutta kalliin valmiuden illuusion varaan.
Mitä SFS-EN ISO 27001 käytännössä kattaa
SFS-EN ISO 27001:n suurin käytännön arvo ei perustu sertifikaattiin sinänsä, vaan siihen, että asianmukaisesti toteutettu järjestelmä tekee tietoturvallisuudesta johdetun kokonaisuuden. Sen tuki on vahvimmillaan prosessimaista toimintaa edellyttävissä asioissa: riskien arvioinnissa ja käsittelyssä, toimintaperiaatteiden ja valvontakäytäntöjen rakentamisessa, roolien ja vastuiden määrittämisessä, tietovarojen tunnistamisessa, poikkeamien hallinnassa, toiminnan jatkuvuudessa sekä katselmointi- ja jatkuvan parantamisen mekanismeissa. Kun nämä osa-alueet toimivat käytännössä eivätkä vain auditointia varten, organisaatiolla on vahva perusta osoittaa, että tietoturvallisuus ei ole joukko erillisiä kontrolleja vaan operatiiviseen päätöksentekoon kytketty hallintajärjestelmä.
Johdon on silti tarkasteltava sertifikaatin sijasta sen hyödyllisyyttä sääntelyn kannalta merkityksellisiin palveluihin, prosesseihin ja riippuvuuksiin nähden. Sama sertifikaatti voi tarkoittaa kypsää järjestelmää, joka kattaa kriittiset prosessit, säännölliset katselmukset, korjaavat toimenpiteet ja prosessinomistajien todellisen ohjauksen. Toisaalta se voi koskea vain rajattua osaa organisaatiosta. Ennen NIS2- ja KSC-vaatimuksiin perustuvaa itsearviointia on siksi syytä tarkastaa soveltuvuuslausunnon lisäksi riskien arviointiin sisältyvät prosessit, sisäisten auditointien tulokset, johdon katselmusten päätökset sekä se, näkyvätkö riskipäätökset budjetissa, sopimuksissa, palveluarkkitehtuurissa ja reagointikäytännöissä.
Tämä näkyy selvästi toimitusketjuissa toimivissa yrityksissä. SFS-EN ISO 27001 jäsentää yleensä sopimusvaatimuksia, tiedon luokittelua, käyttöoikeusperiaatteita, toimittajien vastuita ja poikkeusten dokumentointia. Se on hyödyllinen perusta erityisesti silloin, kun asiakkaat edellyttävät näyttöä kumppaneihin kohdistuvasta valvonnasta. Standardi ei kuitenkaan automaattisesti ratkaise kaikkia toimialakohtaisia odotuksia tai erityiskriteerejä. Sama valintatilanne tulee esiin artikkelissa SFS-EN ISO 27001 vai TISAX – kumpi valitaan, kun asiakas edellyttää tietoturvallisuutta toimitusketjussa? Käytännössä sertifikaatti auttaa hallitsemaan suhteita ja vastuita, mutta se ei korvaa sen selvittämistä, mitä lisävelvoitteita sopimuksiin, eskalointimenettelyihin ja ulkoisten palvelujen valvontaan on sisällytettävä.
| Hallintajärjestelmän osa-alue | Tyypillinen merkitys NIS2/KSC-vaatimuksissa | SFS-EN ISO 27001:n kattavuus |
|---|---|---|
| Riskienhallinta | Toimenpiteiden valinnan perustelu, suojaamisen prioriteetit ja johdon päätökset | Kattava viitekehys; todellinen kattavuus riippuu toteutuksen laadusta |
| Toimintaperiaatteet, roolit ja vastuut | Valvonnan, tehtävien ja katselmointijakson osoittaminen | Kattava tai osittainen järjestelmän soveltamisalasta riippuen |
| Tietovarat ja käyttöoikeudet | Suojattavien kohteiden ja niistä vastaavien henkilöiden tunnistaminen | Osittaisesta kattavaan |
| Poikkeamiin reagointi | Organisatorinen valmius, eskalointireitit sekä tapahtumien kirjaaminen ja analysointi | Osittainen; edellyttää täsmentämistä sääntelyvelvoitteita varten |
| Toiminnan jatkuvuus | Palvelujen ylläpitäminen ja palauttaminen häiriön jälkeen | Osittaisesta kattavaan |
| Toimittajien valvonta | Kumppaneihin kohdistuvat vaatimukset, sopimukset ja riippuvuuksien arviointi | Osittainen; ei korvaa toimialakohtaisia eikä lakisääteisiä vaatimuksia |
| Auditoinnit, katselmukset ja korjaavat toimenpiteet | Näyttö järjestelmän toimivuudesta ja jatkuvasta parantamisesta | Kattava johtamismekanismi |
Johtopäätös on selvä: sertifikaatti voi lyhentää merkittävästi matkaa järjestelmälliseen tietoturvallisuuden hallintaan, mutta se ei yksin osoita KSC-velvoitteiden täyttymistä. Sertifiointiauditoinnissa arvioidaan hallintajärjestelmän standardinmukaisuutta määritellyssä soveltamisalassa. Se ei ole sama asia kuin lakisääteisten velvoitteiden ja operatiivisen valmiuden arviointi. Organisaation on siksi tarkastettava rinnakkain, kattaako järjestelmän soveltamisala olennaiset prosessit, onko riskien arviointi päivitetty todellisten palvelujen ja riippuvuuksien mukaiseksi sekä toimivatko poikkeamien hallintaa, jatkuvuutta ja toimittajavalvontaa koskevat menettelyt käytännössä.
Missä sertifikaatti ei riitä
Ensimmäinen puute liittyy itse sääntelyvaatimusten mukaisuuteen. Tietoturvallisuuden hallintajärjestelmä jäsentää periaatteet, roolit ja valvonnan, mutta se ei itsessään ratkaise, onko organisaation asema KSC-velvoitteiden kannalta tunnistettu oikein, kuka vastaa virallisista ilmoituksista, kuka ylläpitää yhteyttä toimivaltaiseen viranomaiseen ja miten päätökset eskaloidaan johdolle. Kyse ei ole yksittäisen asiakirjan puuttumisesta vaan vastuumallin rakenteellisesta virheestä. Ellei näitä elementtejä liitetä yrityksen todelliseen toimintamalliin, sertifikaatti luo sisäistä järjestystä mutta ei vielä sääntelyn edellyttämää ohjattavuutta.
Toinen puute koskee soveltamisalaa. Monen organisaation sertifiointi rajoittuu tiettyyn toimipaikkaan, yhteen konserniyhtiöön, tiettyyn toimintoon tai osaan tukipalveluista. KSC-valmiutta on kuitenkin arvioitava todellisen palvelukartan, kriittisten prosessien, resurssien ja riippuvuuksien perusteella, ei sertifiointiauditoinnin rajojen mukaan. Jos olennainen tai tärkeä palvelu tuotetaan usean konserniyhtiön yhteistyönä ulkoisen datakeskuksen, yhteisen ylläpitotiimin tai hajautetun poikkeamanhallintaprosessin avulla, muodollisesti asianmukainen sertifikaatti voi kattaa vain osan kokonaisuudesta. Johdon päätös ei tällöin rajoitu siihen, laajennetaanko sertifikaattia. On ratkaistava, toteutetaanko yksi integroitu vaatimustenmukaisuushanke vai kaksi rinnakkaista kokonaisuutta: sertifiointi ja sääntelyvaatimusten hallinta.
Kolmas puute koskee näyttöä ja tulee yleensä esiin vasta poikkeaman, harjoituksen tai tarkastuksen yhteydessä. Organisaatiolla voi olla poikkeamanhallintaa, toiminnan jatkuvuutta ja toimittajavalvontaa koskevat menettelyt, mutta se ei pysty osoittamaan mekanismien operatiivista toimivuutta. Poikkeamarekisteri, johdon päätösten jäljitettävyys, harjoitustulokset, tapahtumien jälkeiset katselmukset, vaikuttavuusmittarit tai dokumentoidut korjaavat toimenpiteet voivat puuttua. Tällöin järjestelmä on kuvattu mutta sen toimivuutta ei ole todennettu. Tässä kohdassa korjaukset ovat yleensä kalleimpia, koska menettelyjen sisällön lisäksi on muutettava johdon raportointia, katselmointirytmiä ja prosessinomistajien vastuuta. Sama ilmiö näkyy muissakin hallintajärjestelmissä, esimerkiksi artikkelissa IATF 16949 – mitkä vaatimukset aiheuttavat todellisia haasteita päivittäisessä laadunhallinnassa ja miten niitä hallitaan ilman näennäistä vaatimustenmukaisuutta?
Neljäs puute liittyy toimitusketjuun ja ulkoisiin riippuvuuksiin. Standardi auttaa jäsentämään toimittajavaatimuksia, mutta KSC-vaatimustenmukaisuus voi edellyttää yksityiskohtaisempaa kartoitusta: mitkä ulkoiset palvelut ylläpitävät kriittisen palvelun tuottamista, missä ovat yksittäiset vikaantumispisteet, millaisia häiriöskenaarioita on tunnistettu ja miten toimittaja, henkilöstö tai toimipaikka voidaan korvata. Käytännössä ei siis riitä, että sopimukset ja toimittaja-arvioinnit ovat olemassa. On seurattava sertifiointilaajuuden vastaavuutta kriittisten palvelujen todelliseen karttaan, poikkeama- ja harjoitusrekisterien kattavuutta sekä toimittaja- ja riippuvuuskatselmusten ajantasaisuutta. Vasta tämä kokonaisuus osoittaa, onko organisaatiolla toimiva järjestelmä vai vain sen muodollinen kuva.
Vaatimustenmukaisuus rakennetaan palveluista, ei asiakirjoista
Yleisin alkuvaiheen virhe on käynnistää hanke SFS-EN ISO 27001 -toimintaperiaatteiden, menettelyohjeiden ja tallenteiden tarkastelulla sen sijaan, että ensin kysyttäisiin, mitkä palvelut on todella pystyttävä ylläpitämään ja mitä sääntelyvelvoitteita niihin liittyy. Oikea työjärjestys on päinvastainen: ensin tunnistetaan palvelut, prosessit, resurssit ja riippuvuudet, jotka ovat toiminnan jatkuvuuden ja KSC-vastuiden kannalta kriittisiä. Vasta tämän jälkeen niihin kohdistetaan hallintajärjestelmän vaatimukset ja näyttötarpeet. Näin voidaan erottaa tarpeellinen dokumentaatio tarpeettomasta.
Johdon on päätettävä kriittisten palvelujen, toimittajariippuvuuksien ja järjestelmien kartan laatimisesta sekä tunnistettava nykyiset menettelyt, joita voidaan hyödyntää ilman päällekkäisten mekanismien rakentamista. Vasta tämän perusteella nähdään, kattaako nykyinen järjestelmä palvelun jatkuvuuden ja vaatimustenmukaisuuden kannalta olennaiset asiat vai pelkästään sen, mikä on historiallisesti sisällytetty sertifiointilaajuuteen.
Toinen vaihe koskee vastuumallia. Jos tietoturvallisuuteen liittyvät tehtävät jakautuvat tietohallinnon, laadun, compliance-toiminnon, kunnossapidon ja hankinnan kesken ilman yksiselitteistä roolijakoa, hanke muuttuu nopeasti paikallisten aloitteiden kokoelmaksi. On määritettävä, kuka vastaa riskistä, kuka johtaa poikkeaman käsittelyä, kuka valvoo toimittajasuhteita, kuka tekee johdon päätökset ja kuka ylläpitää vaatimustenmukaisuutta osoittavaa näyttöä. Käytännössä selkeä rooli- ja vastuumatriisi sekä yksi johdon katselmointirytmi toimivat paremmin kuin useat rinnakkaiset raportointikanavat. Tässä vaiheessa on myös ratkaistava, perustetaanko vaatimustenmukaisuudelle ja tietoturvallisuudelle yhteinen ohjausryhmä ja liitetäänkö operatiivinen teknologia samaan riskienhallintamalliin.
Tuotanto- ja monitoimipaikkaorganisaatioissa tällä lähestymistavalla on erityinen merkitys. Poikkeaman vaikutukset eivät rajoitu tiedon luottamuksellisuuden menetykseen, vaan ne voivat pysäyttää tuotantolinjan, häiritä tuotannonsuunnittelua, heikentää erien jäljitettävyyttä tai estää palvelun tuottamisen. Tietoturvallisuus on siksi yhdistettävä toiminnan jatkuvuuteen, kunnossapitoon ja operatiivisen teknologian ympäristöihin. Jos hallintajärjestelmä kattaa vain toimistoympäristön mutta jättää ulkopuolelle ohjausjärjestelmät, etähuollon, järjestelmäintegraattoririippuvuudet tai toimipaikan hätämenettelyt, riskikuva voi olla muodollisesti jäsennelty mutta operatiivisesti puutteellinen. Samaa suunnittelukuria tarvitaan muillakin vahvasti valvotuilla aloilla, joilla sovelletaan esimerkiksi viitekehyksiä ASME, NQA-1 ja ISO 19443 – kolme lyhennettä, jotka ydinalan toimittajan on tunnettava.
Vasta tämän perustan jälkeen nykyistä SFS-EN ISO 27001 -järjestelmää kannattaa hyödyntää pohjakerroksena ja toteuttaa erillinen KSC-puuteanalyysi. Tarkoitus ei ole kyseenalaistaa sertifikaattia, vaan selvittää, missä vaatimukset ovat jo katettuja ja missä tarvitaan täydentäviä menettelyjä, rekistereitä, eskalointireittejä tai toimivuusnäyttöä. Tämä lähestymistapa rajoittaa tarpeetonta dokumentaatiota ja varmistaa mekanismien yhdenmukaisuuden paremmin kuin erilliset, keskenään kilpailevat hankkeet.
Miten nykytila todennetaan ennen auditointia tai tarkastusta
Ennen auditointia, itsearviointia tai tarkastusta ei pidä kysyä, ”onko organisaatiolla SFS-EN ISO 27001”, vaan pystyykö se osoittamaan todellisen toimintavalmiuden ja päätösten jäljitettävyyden. Valmiutta kannattaa arvioida neljässä kerroksessa: ensin määritetään velvoitteiden soveltamisala ja organisaation asema, sitten tarkastetaan hallintajärjestelmän rakenne, tämän jälkeen prosessien vaikuttavuus ja lopuksi näytön kattavuus. Vain näin dokumenttien hallinta voidaan erottaa operatiivisesta suorituskyvystä.
Hyödyllisimmät kysymykset eivät ole ”onko meillä menettelyohje”, vaan ”tiedämmekö, milloin se käynnistetään, kuka tekee päätöksen, mitkä ovat eskalointikynnykset, miten toiminta osoitetaan jälkikäteen ja onko skenaariota harjoiteltu”. Jos poikkeaman käsittely riippuu yhden henkilön tiedosta, toimittajasuhteille ei ole määritetty tietoturvakriteerejä ja johto saa vain yleisluonteisia raportteja ilman päätöksiä ja määräaikoja, järjestelmä voi vastata omaa dokumentoitua kuvaustaan mutta olla silti valmistautumaton toimimaan paineen alla.
Valmiuskatselmuksen on siksi katettava johdon, operatiivisen toiminnan, tietohallinnon, kunnossapidon ja toimittajien väliset rajapinnat. Juuri niissä ilmenevät useimmiten puutteet, joita menettelyohjeista ei voi nähdä. Käytännössä tehokkain ratkaisu on operatiivisen auditoinnin kaltainen puuteanalyysi. Siinä arvioidaan asiakirjojen lisäksi päätöksentekoketjua, eskalointireittejä, poikkeamatallenteita, testien ja harjoitusten tuloksia sekä poikkeamien, havaintojen ja korjaavien toimenpiteiden rekisteriä.
Hyvä käytännön testi on yksinkertainen skenaario: kriittisen toimittajan ympäristössä tapahtuu poikkeama tai tuotantoympäristössä ilmenee häiriö. Tällöin on pystyttävä määrittämään, kuka luokittelee tapahtuman, kuka käynnistää viestinnän, kuka arvioi vaikutuksen palveluun ja mitä näyttöä päätöksestä jää. Jos vastaukset ovat hajallaan ja organisaatio vetoaa ”vakiintuneeseen käytäntöön”, jota ei voida jäljittää tallenteista, valmius on näennäinen myös silloin, kun hallintajärjestelmää ylläpidetään muuten asianmukaisesti.
Jos organisaatio tekee jo SFS-EN ISO 27001 -sisäisiä auditointeja, niitä kannattaa hyödyntää tässä arvioinnissa. Auditointikriteerejä on kuitenkin laajennettava sääntelyvelvoitteisiin ja KSC-näkökulmasta odotettavaan näyttöön. Auditointiosaamisesta on tässä huomattavaa hyötyä, samoin kuin pääauditoijan tai sisäisen auditoijan tehtäviin valmistautuvien henkilöiden osaamisesta. Luonteva vertailukohta on myös materiaali SFS-EN ISO 27001 -pääauditoija: kattava opas sertifiointiin ja standardin vaatimuksiin. Työjärjestys on kuitenkin säilytettävä oikeana: auditointiosaaminen auttaa arvioimaan järjestelmää, mutta se ei korvaa organisaatioon sovellettavien oikeudellisten ja organisatoristen velvoitteiden analysointia.
Johdon päätös: sertifikaatti perustaksi, ei tekosyyksi
Järkevin lähestymistapa on käyttää SFS-EN ISO 27001 -standardia johtamisrakenteen perustana, ei itsenäisenä todisteena kaikkien NIS2- ja KSC-velvoitteiden täyttymisestä. Sertifikaatti tukee vastuiden, riskien arvioinnin, poikkeamien valvonnan, auditointien ja jatkuvan parantamisen hallintaa. Se ei kuitenkaan poista tarvetta selvittää, mitä velvoitteita organisaatioon tosiasiallisesti sovelletaan, missä laajuudessa ja millaista näyttöä toiminnan vaikuttavuudesta tarvitaan.
Johdon näkökulmasta suurin riski ei ole dokumentaatiopuute vaan valmiuden illuusio: oletus siitä, että sertifioitu järjestelmä tarkoittaa automaattisesti valmiutta myös kansallisen sääntelyn vaatimuksiin. Päätöksen ei siksi pidä koskea vain sertifioinnin ylläpitämistä tai laajentamista. Ensin on ratkaistava kolme johtamiskysymystä:
- vahvistetaan organisaation asema ja sovellettavien velvoitteiden laajuus,
- toteutetaan nykyisen järjestelmän ja KSC-vaatimusten välinen puuteanalyysi,
- määritetään toimenpiteiden toteutuksen ja vaikuttavuusnäytön valvontamalli.
Vasta tämän perusteella voidaan perustellusti päättää, onko sertifioinnin soveltamisalaa laajennettava vai voidaanko nykyistä SFS-EN ISO 27001 -järjestelmää hyödyntää sellaisenaan ja täydentää sitä puuttuvilla organisatorisilla, oikeudellisilla ja operatiivisilla mekanismeilla. Käytännössä päätöksentekoa tukee kolme yksinkertaista johtamisvälinettä: kriittisten prosessien karttaan verrattu ajantasainen sertifiointilaajuus, riski- ja vaatimustenmukaisuusvaikutusten perusteella arvioitu puutelista sekä toimintasuunnitelma vastuuhenkilöineen, määräaikoineen ja sulkemiskriteereineen.
Jos organisaatio vasta valitsee etenemistapaansa, työjärjestys ei ole kaikille sama. Kun asiakkaiden paine tai tarjouskilpailuvaatimukset ovat voimakkaita, järjestelmän rakentaminen sertifiointia varten voi olla perusteltu ensimmäinen vaihe, kunhan sääntelyvelvoitteiden analysointia ei samalla lykätä. Korkean operatiivisen riskin tai hajautuneen vastuumallin organisaatioissa voi puolestaan olla järkevämpää sulkea ensin sääntelyyn liittyvät puutteet ja järjestää sertifioinnin soveltamisala vasta sen jälkeen. Kyse ei ole muodollisuuksien järjestyksestä vaan riskien vähentämisen priorisoinnista. Myös artikkelia ISO-sertifikaatti: hyödyt ja käyttöönottoprosessi kannattaa tarkastella osana laajempaa vaatimustenmukaisuuden johtamista, ei yrityksen toimintamallista irrallisena tavoitteena.
Parhaat tulokset saavutetaan yhdellä yhtenäisellä ohjelmalla, jossa tietoturvallisuutta, toiminnan jatkuvuutta, toimittajavalvontaa ja sääntelyvelvoitteita johdetaan osana yrityksen operatiivista mallia eikä eri toimintojen erillisinä hankkeina. Puolalaisissa organisaatioissa juuri vastuiden pirstoutuminen heikentää usein sekä toimintakykyä että näytön laatua. Lopputulos on yksinkertainen: sertifikaatti auttaa ja voi lyhentää merkittävästi matkaa hallittuun järjestelmään, mutta NIS2- ja KSC-vaatimusten mukaisuus on silti suunniteltava, toteutettava ja osoitettava asianmukaisella näytöllä.
Masz pytania? Porozmawiajmy.
Bezpłatna konsultacja – bez zobowiązań.
