NIS2 ja identiteetinhallinta – käytännön tarkistuslista pohjoismaisille organisaatioille

27.08.2026

NIS2 ja identiteetinhallinta – käytännön tarkistuslista pohjoismaisille organisaatioille

Kirjoittaja: Veli-Pekka Vähälummukka, Trivoren Program Director

NIS2 on nyt arkipäivää Pohjoismaissa. Se näkyy kansallisessa lainsäädännössä, uusissa vaatimuksissa ja käytännön työssä. Samalla organisaatiot joutuvat miettimään entistä tarkemmin, kenellä on pääsy mihinkin järjestelmiin ja miten käyttöoikeuksia hallitaan.

Jos työskentelet identiteetinhallinnan, tietoturvan tai vaatimustenmukaisuuden parissa, tämä koskee sinua konkreettisesti sen kautta, mitä tiimisi pitää saada aikaan seuraavan kahdentoista kuukauden aikana.

Tässä tekstissä käyn läpi, mitä NIS2 todella vaatii identiteettijärjestelmiltä, tarjoan käytännön tarkistuslistan ja nostan esiin virheet, joita näemme organisaatioiden tekevän valmistautuessaan.

Missä Pohjoismaat ovat NIS2-toimeenpanossa

Direktiivi on eurooppalainen, mutta toimeenpano on kansallista. Jokainen Pohjoismaa on saattanut NIS2:n osaksi omaa lainsäädäntöään omassa aikataulussaan:

  • Suomi sai kyberturvallisuuslain voimaan huhtikuussa 2025. Se on nyt täydessä voimassa ja valvonta on käynnissä.
  • Tanska aloitti valvonnan heinäkuussa 2025 osana olemassa olevaa kriittisen infrastruktuurin sääntelykehystään.
  • Ruotsi pani NIS2-lakinsa täytäntöön 15. tammikuuta 2026. Se koskee sekä keskeisiä että tärkeitä toimijoita.
  • Norja tuo ETA-sopimuksen kautta noin 5 000 organisaatiota sääntelyn piiriin heinäkuuhun 2026 mennessä. Ensimmäiset viranomaisauditoinnit odotetaan lokakuussa 2026.

Kaikki neljä maata valitsivat niin sanotun minimalistisen täytäntöönpanon – pysyivät lähellä direktiivin peruslinjaa ilman kansallisia lisävaatimuksia. Tämä tarkoittaa, että vaatimukset ovat pitkälti yhtenevät yli rajojen, mikä helpottaa useassa Pohjoismaassa toimivien organisaatioiden tilannetta.

Yksi asia ansaitsee erityishuomion: henkilökohtainen vastuu. Suomen kyberturvallisuuslaki asettaa riskienhallinnan vastuun nimenomaisesti ylimmälle johdolle. Tämä muuttaa keskustelun suuntaa: ”IT hoitaa vaatimustenmukaisuuden” muuttuu muotoon ”hallituksen täytyy ymmärtää identiteettitilanteemme.” Ruotsissa ja Norjassa on vastaavat säännökset.

Direktiivi on identiteetinhallinnan osalta yllättävän täsmällinen. Artikla 21(2)(i) vaatii ”pääsyoikeuksien hallintapolitiikoita” osana kyberturvallisuuden riskienhallintaa. Artikla 21(2)(j) vaatii ”monivaiheista todennusta tai jatkuvaa todennusta”. Nämä eivät ole piilossa liitteissä, vaan ne on nimetty suoraan ydintekstissä.

Mitä NIS2 todella vaatii identiteettijärjestelmiltäsi

Käännetään lakiteksti käytännön kielelle. NIS2 koskettaa suoraan kuutta identiteetinhallinnan osa-aluetta:

1. Pääsyoikeuksien hallintapolitiikat: dokumentoidut, täytäntöön laitetut, auditoitavat

Pelkät pääsynhallintatoimet eivät riitä. Direktiivi edellyttää dokumentoituja käytäntöjä, jotka määrittelevät kuka saa pääsyn mihin, millä ehdoilla ja miten niitä valvotaan. Monella organisaatiolla on epävirallisia käytäntöjä, mutta auditoijan odottama dokumentaatio puuttuu. Kuilu ei yleensä ole itse kontrolleissa, vaan kyvyssä osoittaa ne.

2. Vahva todennus: MFA lähtötasona

Monivaiheinen todennus mainitaan direktiivissä nimeltä. Vaatimus kattaa muutakin kuin asiakasnäkymän: hallintaliittymät, API-yhteydet ja sisäiset järjestelmät, joissa käsitellään arkaluonteista tietoa, kuuluvat kaikki tämän piiriin. Organisaatiot, jotka ovat ottaneet MFA:n käyttöön asiakassovelluksissa mutta jättäneet sisäiset työkalut yhden tekijän varaan, täyttävät vaatimuksen vain osittain.

3. Toimitusketjun turvallisuus: identiteetinhallinta ulottuu toimittajiin ja kumppaneihin

NIS2 edellyttää, että organisaatiot huomioivat toimitusketjunsa riskit. Identiteetinhallinnan näkökulmasta tämä tarkoittaa, että alihankkijoiden ja kumppaneiden pääsyoikeudet on hallittava samalla tarkkuudella kuin työntekijöiden. Useimmissa organisaatioissa juuri tässä kohdassa hallinta pettää, kun alihankkijoiden oikeudet myönnetään manuaalisesti, niitä tarkistetaan harvoin ja ne unohtuvat aktiivisiksi lähdönhetkellä.

4. Poikkeamien käsittely: kuka pääsi ja mihin tietomurron hetkellä?

Tietoturvapoikkeaman sattuessa yksi ensimmäisistä kysymyksistä on: millä identiteeteillä oli pääsy kyseisiin järjestelmiin? Jos et pysty rekonstruoimaan pääsyoikeustilannetta poikkeaman ajanhetkenä – et nykyhetken, vaan tapahtumahetken – sinulla on aukko. Tämä vaatii ajankohtakohtaisia pääsyoikeustietoja, ei pelkkää nykytilaa.

5. Lokitus ja jäljitettävyys: muuttumattomat, saatavilla olevat ja koko elinkaaren kattavat

Jäljityslokin täytyy kattaa identiteetin koko elinkaari: luonti, muutokset, oikeuksien myöntämiset ja poistot, todennustapahtumat ja käytön lopetus. Lokien on oltava muuttumattomia (ei muokattavissa jälkikäteen) ja säilytettävä sääntelyn edellyttämän ajan. Loki, joka näyttää vain nykyisen pääsyoikeustilanteen, ei riitä.

6. Etuoikeutettujen käyttäjien hallinta: korotetut oikeudet seurannassa ja tarkistuksessa

Tileille, joilla on korotetut oikeudet – järjestelmävalvojat, tietokantaomistajat, palvelutilit laajoilla oikeuksilla – tarvitaan lisävalvontaa. NIS2 edellyttää, että nämä tilit inventoidaan, niitä valvotaan ja ne tarkistetaan säännöllisesti. Yleinen käytäntö, jossa jaetaan ylläpitotunnuksia staattisilla salasanoilla, on suora vaatimustenmukaisuusriski.

Kaava on sama kaikissa kuudessa kohdassa: NIS2 ei vaadi täydellisyyttä. Se vaatii dokumentoidut, täytäntöönpannut ja auditoitavat prosessit. Suurimmalla osalla pohjoismaisista organisaatioista kuilu ei ole teknologiassa vaan hallinnossa – politiikoissa, tarkistuksissa ja todisteissa, jotka muuttavat työkalut kontrolleiksi.

10 kohdan identiteettitarkistuslista

Nämä ovat konkreettisia toimenpiteitä. Jokaisen kohdalla kerromme, onko kyseessä suora NIS2-vaatimus vai hyvä käytäntö, joka tukee vaatimustenmukaisuutta.

1. Kartoita kaikki identiteettien lähteet.

Ennen kuin voit hallita identiteettejä, sinun pitää tietää missä niitä on. HR-järjestelmät, Active Directory, pilvikäyttäjähakemistot, alihankkijatietokannat, jaetut Excel-taulukot – monessa organisaatiossa identiteettitietoa on hajallaan viidessä tai useammassa lähteessä. Ennen kuin sinulla on kattava kartta, et pysty arvioimaan riskejäsi.

NIS2-relevanssi: perusta pääsyoikeuksien hallintapolitiikoille.

2. Nimeä yksi määräävä identiteettivarasto.

Yhden järjestelmän täytyy olla identiteetin totuuden lähde. Tämä ei tarkoita muiden järjestelmien hylkäämistä – se tarkoittaa, että yksi järjestelmä on määräävä ja muut lähteet syöttävät siihen. Ilman tätä sinulla on aina ristiriitaista tietoa siitä, kenellä on pääsy mihin.

NIS2-relevanssi: edellytys osoitettavalle pääsyoikeuksien hallinnalle.

3. Ota MFA käyttöön kaikissa järjestelmissä.

Eikä vain asiakasnäkymissä. Hallintakonsolit, VPN-yhteydet, API-hallintaportaalit, arkaluonteista tietoa käsittelevät sisäiset työkalut – kaikki tarvitsevat monivaiheisen todennuksen. Priorisoi järjestelmät sen mukaan, miten arkaluonteista tietoa ne suojaavat ja kuinka korkealla tasolla niiden käyttäjien oikeudet ovat.

NIS2-relevanssi: suoraan artikla 21(2)(j):n vaatima.

4. Automatisoi identiteetin elinkaari: aloitus, muutos sekä lopetus.

Kun joku aloittaa organisaatiossa, vaihtaa roolia tai lähtee, pääsyoikeuksien täytyy muuttua automaattisesti hänen suhteensa perusteella organisaatioon – eikä tikettiin perustuen, jonka joku ehkä muistaa laittaa. Manuaalinen oikeuksien perustaminen ja poistaminen on suurin yksittäinen pääsyoikeuksien hallinnan epäonnistumisten lähde.

NIS2-relevanssi: tukee täytäntöönpantavia pääsyoikeuspolitiikoita ja poikkeamavalmiutta.

5. Käyttöoikeuksien säännöllinen katselmointi – vähintään neljännesvuosittain.

Rakenteellinen prosessi, jossa esimiehet tai järjestelmien omistajat vahvistavat, että heidän alueeseensa kuuluvien henkilöiden pääsyoikeudet ovat edelleen asianmukaisia. Sertifiointikierrosten pitää kattaa sekä tavalliset että etuoikeutetut tilit.

NIS2-relevanssi: tukee suoraan auditoitavaa pääsyoikeuksien hallintaa.

6. Pane toimeen tehtävien eriyttämissäännöt.

Tietyt pääsyoikeusyhdistelmät luovat liian suuren riskin – esimerkiksi kyky sekä luoda että hyväksyä rahoitustapahtumia. Nämä säännöt on määriteltävä, koodattava identiteettijärjestelmiin ja pantava täytäntöön automaattisesti. Manuaalinen valvonta ei skaalaudu eikä tyydytä auditointivaatimuksia.

NIS2-relevanssi: hyvä käytäntö, joka tukee riskienhallintavelvoitteita.

7. Tuo ei-inhimilliset identiteetit hallinnan piiriin.

Palvelutilit, API-avaimet, koneidentiteetit ja yhä useammin tekoälyagentit ovat kaikki identiteettejä, jotka pääsevät käsiksi järjestelmiisi. Useimmat organisaatiot hallitsevat ihmisidentiteettejä kohtuullisesti, mutta näkyvyys ei-inhimillisiin identiteetteihin on rajallinen. Näiden pitää käydä läpi sama elinkaari: luonti, tarkistus, uusiminen ja käytön lopetus.

NIS2-relevanssi: pääsyoikeuspolitiikoiden on katettava kaikki verkko- ja tietojärjestelmiin pääsevät identiteetit.

8. Varmista jäljityslokin muuttumattomuus ja erillinen säilytys.

Identiteettitapahtumalokin pitää olla peukaloinnilta suojattu ja säilytettynä erillään järjestelmistä, joita se valvoo. Jos hyökkääjä pystyy murron yhteydessä muokkaamaan myös lokia, loki on arvoton. Erillinen säilytys, kertakirjoitusperiaate ja eheyden todentaminen ovat vähimmäistaso.

NIS2-relevanssi: suoraan vaatimus poikkeamien käsittelylle ja viranomaisraportoinnille.

9. Dokumentoi ja testaa hätätilannemenettelyt.

Mitä tapahtuu, kun ensisijainen identiteettipalveluntarjoajasi on pois käytöstä? Hätätilanteen pääsyoikeusmenettely – niin sanottu break-glass – on dokumentoitava, säilytettävä turvallisesti (mukaan lukien offline-kopiot) ja testattava säännöllisesti. Menettely, jota ei ole koskaan testattu, on suunnitelma, ei kyvykkyys.

NIS2-relevanssi: tukee liiketoiminnan jatkuvuutta ja poikkeamien käsittelyvaatimuksia.

10. Nimitä identiteetinhallinnan omistaja johtotasolla.

Jonkun johtotasolla – ei IT-tiimissä, vaan ylimmän johdon osana tai sille raportoivana – on omistettava identiteetinhallinta. Tämä henkilö vastaa politiikoista, tarkistuksista ja vaatimustenmukaisuustilanteesta. NIS2:n alla, erityisesti Suomen kyberturvallisuuslain henkilökohtaisen vastuun säännösten myötä, tämä ei ole vapaaehtoista.

NIS2-relevanssi: suoraan johdon vastuuvelvoitteiden vaatima.

Mitä useimmat organisaatiot tekevät väärin

Neljä samaa kaavaa toistuu organisaatiosta toiseen:

1. NIS2 nähdään pelkkänä IT-hankkeena.

Direktiivi edellyttää nimenomaisesti ylimmän johdon osallistumista riskienhallintaan. Identiteetinhallinta ei ole asia, jonka voi delegoida kokonaan tietoturvatiimille ja katsoa hoidetuksi. Johdon on ymmärrettävä identiteettitilanne, hyväksyttävä politiikat ja otettava vastuu jäännösriskistä. Kun Traficomin tai muun valvovan viranomaisen edustaja tulee asiasta kysymään, niin ”IT hoitaa sen” ei ole hyväksyttävä vastaus.

2. Keskitytään kehäturvallisuuteen ja jätetään identiteetinhallinta manuaalisten prosessien varaan.

Monet organisaatiot ovat investoineet vahvasti palomuureihin, päätelaitteiden suojaukseen ja verkonvalvontaan. Nämä ovat tärkeitä. Mutta jos identiteetinhallintanne pyörii edelleen Excel-taulukkojen, sähköpostipyyntöjen ja manuaalisten hyväksymisten varassa, on teillä rakenteellinen heikkous. Kehämalli olettaa, että uhat tulevat ulkoa. Identiteetinhallinta puuttuu tilanteisiin, joissa joku sisällä – tai joku, jonka ei pitäisi enää olla sisällä – pääsee käsiksi enempaan kuin pitäisi.

3. Oletetaan, että Microsoft Entra ID kattaa hallinnan.

Entra ID on kelpo identiteettipalveluntarjoaja. Se hoitaa todennuksen, federaation ja ehdollisen pääsyn hyvin. Mutta se ei ole identiteetin hallinnan ja hallinnon (IGA) alusta. Se ei tue natiivisti käyttöoikeuksien sertifiointikierroksia, tehtävien eriyttämisen täytäntöönpanoa, sopimusperusteista elinkaaren hallintaa tai järjestelmien välistä provisiointihallintaa. Organisaatiot, jotka rinnastavat ”meillä on Entra ID” lauseeseen ”meillä on identiteetinhallinta”, sekoittavat todennuksen hallintoon. Nämä ovat eri kerroksia, joilla on eri vaatimukset.

4. Aliarvioidaan ei-inhimillisten identiteettien ongelma.

Jokaista ihmisidentiteettiä kohti tyypillisessä yrityksessä on useita ei-inhimillisiä identiteettejä: palvelutilit, sovellusidentiteetit, API-tunnisteet, automatisoidut prosessit ja nykyään tekoälyagentit. Näillä identiteeteillä on usein laajat oikeudet, ja ne käyvät harvoin läpi saman hallinnan kuin ihmistilit. NIS2 ei tee eroa inhimillisten ja ei-inhimillisten identiteettien välillä vaatiessaan pääsyoikeuspolitiikoita. Eikä sinunkaan pitäisi.

Mistä aloittaa

Jos valmistautuminen ei ole vielä alkanut, aloita identiteettikypsyysarvioinnilla. Tämän ei tarvitse olla kuuden kuukauden konsultointiprojekti. Rakenteellinen katsaus nykyisiin identiteettilähteisiin, hallintaprosesseihin, pääsyoikeuksien katselmointikäytäntöihin ja jäljityslokin kyvykkyyksiin paljastaa suurimmat aukot.

Priorisoi maakohtaisen aikataulun mukaan. Suomessa valvonta on jo käynnissä. Norjassa aikaraja oli heinäkuu 2026, mutta lokakuun 2026 auditoinnit tulevat nopeasti. Ruotsin tammikuun 2026 voimaantulopäivä tarkoittaa, että siellä pitäisi jo olla toteutusvaiheessa, ei suunnittelussa.

Tämän kirjoituksen tarkistuslista on käyttökelpoinen lähtöpiste. Kaikkia kohtia ei tarvitse saada valmiiksi ennen sääntelydeadlinea, mutta jokaisen täytyy olla tiekartalla, aikataulutettuna ja vastuutettuna.

Jos haluat verrata organisaatiosi identiteettitilanteen NIS2-vaatimuksiin, Trivoren tiimi käy arvioinnin mielellään läpi kanssasi. Et joudu kuuntelemaan myyntipuhetta, vaan saat rehellisen katsauksen siihen, missä olette ja mikä vaatii huomiota ensimmäisenä.

Jaa tämä artikkeli:

Pyydä esittelyä

Täytä alla oleva lomake niin otamme sinuun yhteyttä esittelyä varten.

Uutta: Näe kuinka paljon voit säästää modernin IAM:n avulla