ISO 27001:n sisäinen auditointi NIS2:n ja DORA:n tueksi
On vuoden 2026 ensimmäinen tarkastusvaliokunnan kokous. Sarah, nopeasti kasvavan SaaS- ja fintech-palveluntarjoaja FinSecuren tietoturvajohtaja, on saanut esityslistalta viisitoista minuuttia. Hallituksella on viisi kysymystä.
Olemmeko valmiita ISO/IEC 27001:2022 -valvonta-auditointiin? Kuulummeko NIS2:n soveltamisalaan hallinnoituna palveluntarjoajana? Vaikuttaako DORA meihin, koska tuemme finanssisektorin asiakkaita? Voimmeko osoittaa, että poikkeamien ilmoittaminen, toimittajien huolellisuusarviointi ja liiketoiminnan jatkuvuus toimivat käytännössä? Ja miksi viime kvartaalin käyttöoikeuksien katselmointi löysi edelleen käyttäjätilejä, jotka olisi pitänyt poistaa?
Sarahilla on näyttöä, mutta se on hajallaan. Tuotekehitystiimillä on haavoittuvuusskannausten vientitiedostoja. Hankinnalla on toimittajakyselyjä. Lakiasioilla on sopimuslausekkeita. Vaatimustenmukaisuudesta vastaavalla päälliköllä on GDPR-seurantataulukko. SOC:lla on poikkeamien käsittelytikettejä. Mikään niistä ei ole ilmeisen väärin, mutta mikään ei muodosta johdonmukaista varmennuskokonaisuutta.
Tässä kohdassa ISO 27001:n sisäisen auditoinnin ohjelmasta tulee joko strateginen näyttöä tuottava mekanismi tai se jää kerran vuodessa kiireellä koottavaksi aineistoksi.
NIS2:n ja DORA:n piirissä oleville organisaatioille sisäinen auditointi ei voi enää olla muodollinen tarkistuslista. Sen on oltava riskiperusteinen varmennusjärjestelmä, joka vahvistaa, onko ISMS:n soveltamisala oikea, toimivatko kontrollit käytännössä, onko sääntelyvaatimukset kartoitettu, luokitellaanko havainnot yhdenmukaisesti ja päätyvätkö korjaavat toimenpiteet johdon katselmukseen. Vuonna 2026 vahvimmat ohjelmat eivät kysy vain: “Teimmekö auditoinnin?” Ne kysyvät: “Voimmeko osoittaa kuukausi kuukaudelta, että kyberturvallisuuden hallinnointi, ICT-häiriönsietokyky, toimittajaturvallisuus ja valmius poikkeamatilanteisiin toimivat?”
Tämän lähestymistavan Clarysec on sisällyttänyt tuotteisiin Zenith Blueprint: auditoijan 30 askeleen tiekartta, Zenith Controls: vaatimustenmukaisuuskehysten välinen opas sekä Clarysecin politiikkakokonaisuuteen. Tavoitteena ei ole luoda erillisiä ISO-, NIS2- ja DORA-projekteja. Tavoitteena on vahvistaa ISMS:ää niin, että yksi auditointiohjelma tuottaa uudelleenkäytettävää näyttöä useisiin varmennustarpeisiin.
Miksi vuoden 2026 sisäisen auditoinnin ohjelmien on muututtava
NIS2 ja DORA siirsivät auditointikeskustelun dokumentaatiosta hallittuun häiriönsietokykyyn.
NIS2 koskee monia keskisuuria ja suuria organisaatioita kriittisillä ja tärkeillä sektoreilla, kuten digitaalisen infrastruktuurin toimijoita, pilvipalvelujen tarjoajia, datakeskuspalvelujen tarjoajia, hallinnoituja palveluntarjoajia, hallinnoituja tietoturvapalveluntarjoajia, verkossa toimivia markkinapaikkoja, hakukoneita ja sosiaalisen verkostoitumisen alustoja. Jäsenvaltiot alkoivat soveltaa kansallisia toimenpiteitä lokakuusta 2024 alkaen, ja vuoteen 2026 mennessä monet organisaatiot toimivat ensimmäistä kokonaista vuotta kypsien NIS2-odotusten mukaisesti.
DORA:a sovelletaan 17. tammikuuta 2025 alkaen laajaan joukkoon finanssialan toimijoita, kuten luottolaitoksiin, maksulaitoksiin, sähköisen rahan liikkeeseenlaskijoihin, sijoituspalveluyrityksiin, kryptovarapalvelujen tarjoajiin, vakuutus- ja jälleenvakuutusyrityksiin, joukkorahoituspalvelujen tarjoajiin sekä olennaisiin ICT-kolmannen osapuolen palveluntarjoajiin. DORA on finanssialan toimijoita koskeva sektorikohtainen digitaalisen operatiivisen häiriönsietokyvyn sääntelykehys. Finanssialan toimijoita palvelevat ICT-palveluntarjoajat voivat kohdata DORA-vaikutuksia myös sopimusten, tarkastusoikeuksien, testaukseen osallistumisen, poikkeamatilanteiden tuen, alihankinnan kontrollien ja palvelun päättämistä koskevien vaatimusten kautta.
Molemmat säädökset korostavat vastuun osoitettavuutta. NIS2 Article 20 edellyttää, että johtoelimet hyväksyvät ja valvovat kyberturvallisuuden riskienhallintatoimenpiteitä ja saavat kyberturvallisuuskoulutusta. DORA Article 5 tekee johtoelimestä viime kädessä vastuullisen ICT-riskistä, mukaan lukien digitaalisen operatiivisen häiriönsietokyvyn strategian, ICT-politiikkojen, jatkuvuusjärjestelyjen ja kolmannen osapuolen riskien hyväksyminen ja valvonta.
ISO 27001 soveltuu tähän ympäristöön hyvin, koska se on hallintajärjestelmästandardi. Se edellyttää, että organisaatio ymmärtää toimintaympäristönsä, määrittää sidosryhmät ja vaatimukset, asettaa ISMS:n soveltamisalan, arvioi ja käsittelee riskit, seuraa suorituskykyä, toteuttaa sisäiset auditoinnit ja edistää jatkuvaa parantamista. Tarkoitus ei ole pakottaa NIS2:ta ja DORA:a ISO-muottiin. Tarkoitus on käyttää ISO 27001:tä toistettavan varmennuksen käyttöjärjestelmänä.
Aloita soveltamisalasta: auditoi järjestelmä, johon hallitus tukeutuu
Heikko sisäisen auditoinnin ohjelma alkaa epämääräisestä soveltamisalasta, kuten “tietoturvallisuus”. Vahva ohjelma alkaa liiketoiminnan ja sääntelyn rajauksesta.
ISO 27001 edellyttää, että ISMS:n soveltamisalassa huomioidaan sisäiset ja ulkoiset tekijät, sidosryhmien vaatimukset sekä rajapinnat tai riippuvuudet muihin organisaatioihin. Tämä on olennaista, koska NIS2- ja DORA-velvoitteet sijoittuvat usein organisaation rajapinnoille: pilvialustoihin, ulkoistettuihin SOC-palveluntarjoajiin, hallinnoituun havainnointiin ja reagointiin, maksujärjestelmiin, fintech-ohjelmointirajapintoihin, asiakastietojen käsittelyyn, varmuuskopiointipalveluihin ja poikkeamien eskalointikumppaneihin.
Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille asettaa hallinnoinnin perustason:
Toimitusjohtajan on hyväksyttävä vuosittainen auditointisuunnitelma.
Kohdasta ‘Hallinnointivaatimukset’, politiikan kohta 5.1.1.
Suuremmissa ympäristöissä Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka nostaa odotustasoa:
Riskiperusteinen auditointisuunnitelma on laadittava ja hyväksyttävä vuosittain ottaen huomioon:
Kohdasta ‘Hallinnointivaatimukset’, politiikan kohta 5.2.
Soveltamisala ei siis ole pelkkä auditoijan mieltymys. Se on johdon hyväksymä varmennussitoumus.
Vuoden 2026 ISO 27001:n sisäisen auditoinnin ohjelmaan, joka tukee NIS2:ta ja DORA:a, tulisi sisällyttää:
- ISMS:n kohdat ja prosessit, mukaan lukien toimintaympäristö, johtajuus, riskienhallinta, tavoitteet, tukitoiminnot, operatiivinen toiminta, suorituskyvyn arviointi ja parantaminen.
- Olennaiset ISO/IEC 27001:2022 liite A:n kontrollialueet, mukaan lukien toimittajasuhteet, poikkeamien hallinta, liiketoiminnan jatkuvuus, lakisääteiset velvoitteet, tietosuoja, lokitus, seuranta, haavoittuvuuksien hallinta, pääsynhallinta, kryptografia, turvallinen kehittäminen, muutoksenhallinta ja pilvipalvelujen hallinnointi.
- Sääntelykerrokset, mukaan lukien NIS2 Articles 20, 21 and 23, DORA Articles 5, 6, 8 to 14, 17 to 19, 24 to 27 and 28 to 30 sekä GDPR:n turvallisuutta ja osoitusvelvollisuutta koskevat vaatimukset.
- Keskeiset palvelut ja liiketoimintaprosessit, erityisesti kriittiset tai tärkeät toiminnot, olennaiset palvelut, asiakasrajapinnan alustat ja säänneltyjä asiakkaita tukevat järjestelmät.
- Kolmansien osapuolten riippuvuudet, mukaan lukien ICT-toimittajat, pilvipalveluntarjoajat, ulkoistettu kehittäminen, SOC, MSSP, henkilötietojen käsittelijät ja kriittiset alihankkijat.
- Näyttöä tuottavat prosessit, mukaan lukien riskien arvioinnit, käyttöoikeuksien katselmoinnit, haavoittuvuuksien korjaavat toimenpiteet, poikkeamaharjoitukset, varmuuskopioiden palautustestit, toimittajakatselmukset, jatkuvuustestit ja johdon katselmukset.
Zenith Blueprint vahvistaa tämän Auditointi, katselmointi ja parantaminen -vaiheessa, Step 25, Internal Audit Program:
Päätä sisäisen auditointiohjelman soveltamisala. Vuoden aikana sinun on lopulta katettava kaikki olennaiset ISMS-prosessit ja kontrollit.
Auditointi, katselmointi ja parantaminen -vaiheesta, Step 25: Internal Audit Program.
Kaikkea ei tarvitse auditoida joka kuukausi. Vuosisyklin aikana kaikkien olennaisten ISMS-prosessien ja kontrollien tulee kuitenkin tulla katetuiksi, ja korkean riskin sekä säänneltyihin alueisiin tulee kohdistaa työtä useammin.
Rakenna auditointikokonaisuus NIS2- ja DORA-kontrolliteemojen ympärille
NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä. Sen perustasoon kuuluvat riskianalyysi, turvallisuuspolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, varmuuskopioinnin hallinta, katastrofipalautus, kriisinhallinta, toimitusketjun turvallisuus, turvallinen hankinta ja kehittäminen, haavoittuvuuksien käsittely, tehokkuuden arviointi, kyberhygienia, koulutus, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta, MFA tai tarvittaessa jatkuva todennus sekä turvallinen viestintä.
DORA:ssa on samankaltainen operatiivinen elinkaari. Se edellyttää, että finanssialan toimijat tunnistavat ja luokittelevat ICT-tuetut liiketoiminnot, tietovarat, ICT-omaisuuserät, riippuvuudet ja kolmannen osapuolen yhteydet. Se edellyttää myös suojausta, havaitsemista, poikkeamien luokittelua, reagointia, palautumista, varmuuskopiointia, palautusta, testausta, poikkeaman jälkeistä oppimista, viestintää ja ICT-kolmannen osapuolen riskienhallintaa.
Yhtenäinen auditointikokonaisuus estää yleisen virheen, jossa ISO 27001 auditoidaan erillään NIS2:sta ja DORA:sta.
| Auditointialue | ISO 27001 -auditoinnin ankkuri | NIS2- ja DORA-relevanssi | Tyypillinen näyttö |
|---|---|---|---|
| Hallinnointi ja lakisääteiset velvoitteet | Toimintaympäristö, johtajuus, riskien käsittely, lakisääteiset ja sopimusperusteiset vaatimukset | NIS2:n hallitusvalvonta, DORA:n johtoelinvastuu, GDPR:n osoitusvelvollisuus | Lakirekisteri, sidosryhmärekisteri, ISMS:n soveltamisala, riskinottohalukkuus, hallituksen pöytäkirjat, johdon katselmointi |
| Riskien arviointi ja käsittely | Riskien arviointi, soveltuvuuslausunto, riskienkäsittelysuunnitelma | NIS2:n asianmukaiset ja oikeasuhtaiset toimenpiteet, DORA:n ICT-riskien hallinnan viitekehys | Riskirekisteri, riskikriteerit, käsittelyhyväksynnät, jäännösriskin hyväksyntä |
| Omaisuus- ja riippuvuusinventaario | Omaisuudenhallinta, pilvipalvelujen hallinnointi, toimittajapalvelut | DORA:n ICT-omaisuuserät ja yhteydet, NIS2:n palveluntuotantojärjestelmät | CMDB, tietovirtojen kartat, toimittajarekisteri, pilvi-inventaario, kriittisyysluokitus |
| Pääsynhallinta ja identiteetti | Henkilöstöturvallisuus, käyttöoikeuksien hallinta, MFA, etuoikeutettu pääsy | NIS2:n pääsynhallinta ja MFA, DORA:n vähimpien oikeuksien periaate ja vahva tunnistautuminen | JML-tiketit, käyttöoikeuksien katselmoinnit, MFA-raportit, etuoikeutettujen tilien lokit |
| Lokitus, seuranta ja havaitseminen | Lokitus, seuranta, tapahtumien arviointi | DORA:n poikkeamien havaitseminen ja poikkeamien luokittelu, NIS2:n valmius poikkeamatilanteisiin | SIEM-hälytykset, havaitsemissäännöt, poikkeamien luokittelun ja priorisoinnin tallenteet, valvontanäkymät |
| Poikkeamien hallinta | Poikkeamasuunnittelu, reagointi, todisteiden kerääminen, opit | NIS2:n raportointityönkulku, DORA:n ICT-poikkeamien elinkaari | Poikkeamaloki, vakavuusmatriisi, ilmoituspohjat, juurisyyraportit, harjoitustallenteet |
| Liiketoiminnan jatkuvuus ja palautuminen | ICT-valmius, varmuuskopiot, turvallisuus häiriötilanteissa | NIS2:n varmuuskopiointi ja kriisinhallinta, DORA:n jatkuvuus ja palautuminen | BIA, jatkuvuussuunnitelmat, varmuuskopiointitestit, RTO- ja RPO-tallenteet, kriisiviestintätesti |
| Toimittaja- ja ICT-kolmannen osapuolen riski | Toimittajasopimukset, ICT-toimitusketju, pilvipalvelujen hankinta ja irtautuminen | NIS2:n toimitusketjun turvallisuus, DORA:n ICT-kolmannen osapuolen rekisteri ja sopimuslausekkeet | Toimittajien huolellisuusarviointi, sopimukset, tarkastusoikeudet, exit-suunnitelmat, keskittymäriskin analyysi |
| Turvallinen kehittäminen ja haavoittuvuudet | Turvallinen hankinta, kehitys, muutokset, haavoittuvuuksien hallinta | NIS2:n haavoittuvuuksien käsittely, DORA:n paikkaus ja testaus | Haavoittuvuusskannaukset, korjaavien toimenpiteiden palvelutasosopimukset, muutostiketit, koodikatselmointi, penetraatiotestausraportit |
| Vaatimustenmukaisuuden seuranta ja korjaavat toimenpiteet | Seuranta, sisäinen auditointi, poikkeamat ja korjaavat toimenpiteet | NIS2:n korjaavat toimenpiteet, DORA:n auditointi ja korjaavien toimenpiteiden seuranta | Auditointiraportit, CAPA-seuranta, KPI-mittaristo, johdon katselmuksen toimenpiteet |
Tämä rakenne muuttaa jokaisen auditointialueen yhteiseksi varmennuskohteeksi. Sisäinen auditoija testaa ISO 27001 -vaatimuksen ja kirjaa sen jälkeen, tukeeko sama näyttö myös NIS2-, DORA-, GDPR-, NIST CSF- ja COBIT 2019 -odotuksia.
Suunnittele vuosi riskin, ei paperityön, ympärille
Zenith Blueprint antaa tiimeille käytännön järjestyksen, jolla auditointi muutetaan parantamiseksi:
- Step 25, Internal Audit Program: suunnittele soveltamisala, tiheys, riippumattomuus ja riskiperusteiset prioriteetit.
- Step 26, Audit Execution: kerää objektiivista näyttöä haastatteluilla, asiakirjakatselmoinnilla, havainnoinnilla ja otannalla.
- Step 27, Audit Findings, Analysis & Root Cause: luokittele havainnot ja tunnista juurisyy.
- Step 28, Management Review: vie auditointitulokset, poikkeamat, tavoitteet, riskit ja resurssitarpeet johdon katselmukseen.
- Step 29, Continual Improvement: rakenna korjaavat toimenpiteet, jotka poistavat syyt eivätkä vain oireita.
Zenith Blueprint on riippumattomuudesta selkeä:
Ihannetilanteessa sisäisen auditoijan ei tulisi auditoida omaa työtään.
Auditointi, katselmointi ja parantaminen -vaiheesta, Step 25: Internal Audit Program.
Pienemmässä SaaS- tai fintech-yrityksessä tämä voi tarkoittaa, että toisen toiminnon esihenkilö auditoi tietoturvaprosesseja, kontrollien omistajia kierrätetään tai käytetään ulkoista konsulttia. Olennaista on dokumentoida pätevyys ja riippumattomuus erityisesti silloin, kun asiakkaat, sääntelyviranomaiset, valvontaelimet tai ulkoiset auditoijat voivat myöhemmin tarkastella NIS2- ja DORA-näyttöä.
Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille määrittää myös auditoinnin vähimmäisrakenteen:
Jokaisessa auditoinnissa on oltava määritelty soveltamisala, tavoitteet, vastuuhenkilöt ja vaadittava näyttö.
Kohdasta ‘Hallinnointivaatimukset’, politiikan kohta 5.2.3.
Käytännöllinen neljännesvuosirakenne nopeasti kasvavalle SaaS- tai ICT-palveluntarjoajalle voisi olla:
| Kvartaali | Ensisijainen auditointifokus | Sääntelypainotus | Pääasialliset tuotokset |
|---|---|---|---|
| Q1 | Poikkeamien hallinta ja raportointi | NIS2 Article 23, DORA Articles 17 to 19 | Poikkeama-auditointiraportti, ilmoitustyönkulun testi, vakavuusmatriisin katselmointi |
| Q2 | ICT-kolmannen osapuolen riskienhallinta | NIS2 Article 21, DORA Articles 28 to 30 | Toimittajaotanta, sopimuskatselmointi, huolellisuusarvioinnin näyttö, exit-suunnittelun katselmointi |
| Q3 | Liiketoiminnan jatkuvuus ja häiriönsietokyvyn testaus | NIS2 Article 21, DORA Articles 11, 12, 24 to 27 | Varmuuskopioiden palautusnäyttö, jatkuvuusharjoitus, häiriönsietotestin korjaavat toimenpiteet |
| Q4 | Hallinnointi, riskit ja vaatimustenmukaisuus | NIS2 Article 20, DORA Articles 5 and 6, ISO 27001 Clauses 5, 9 and 10 | Johdon katselmointipaketti, CAPA-tila, jäännösriskipäätökset, seuraavan vuoden auditointisuunnitelma |
Tämä ei korvaa kuukausittaista näytön keräämistä. Se antaa vuodelle selkeän varmennusrytmin.
Otanta: kuinka paljon näyttöä on riittävästi?
Otanta on kohta, jossa monet sisäiset auditoinnit muuttuvat joko liian pinnallisiksi tai liian kalliiksi. Säännellyissä ICT-ympäristöissä otannan on oltava riskiperusteista, perusteltavissa ja dokumentoitua.
Zenith Blueprint, Step 26, antaa käytännön periaatteen:
Tee otantoja ja pistokoetarkastuksia: kaikkea ei voi tarkistaa, joten käytä otantaa.
Auditointi, katselmointi ja parantaminen -vaiheesta, Step 26: Audit Execution.
Clarysecin suurorganisaatioille tarkoitettu politiikka tekee tästä auditoitavissa olevan:
Otannan strategian, auditoinnin soveltamisalan ja rajoitusten dokumentointi
Kohdasta ‘Hallinnointivaatimukset’, politiikan kohta 5.5.3.
NIS2:n ja DORA:n osalta otannassa tulee huomioida kriittisyys, riski, toimittajan merkitys, ajanjakso, poikkeamahistoria, maantiede ja se, tukeeko otantaan valittu prosessi kriittisiä tai tärkeitä toimintoja.
| Kontrollialue | Perusjoukko | Ehdotettu otos | Riskiperusteinen mukautus |
|---|---|---|---|
| Käyttöoikeuksien myöntäminen | Kaikki kvartaalin uudet käyttäjätilit | 10 tiliä tai 10 prosenttia, kumpi on suurempi | Sisällytä kaikki etuoikeutetut tilit ja kriittisten sovellusten ylläpitäjät |
| Poistuvan henkilön käyttöoikeuksien poistaminen | Kaikki kvartaalin aikana työsuhteensa päättäneet käyttäjät | 100 prosenttia etuoikeutetuista käyttäjistä, 10 tavallista käyttäjää | Kasvata otosta, jos HR- tai IAM-integraatio on muuttunut |
| Toimittajien huolellisuusarviointi | Aktiiviset ICT-toimittajat | Kaikki kriittiset toimittajat, 5 keskisuuren riskin toimittajaa, 3 matalan riskin toimittajaa | Sisällytä toimittajat, jotka tukevat finanssiasiakkaita tai olennaisia palveluita |
| Haavoittuvuuksien korjaavat toimenpiteet | Kvartaalin aikana suljetut kriittiset ja korkeat havainnot | 15 tikettiä eri järjestelmistä | Sisällytä internetiin näkyvät järjestelmät ja toistuvat poikkeukset |
| Poikkeamien hallinta | Kaikki kvartaalin tietoturvapoikkeamat | Kaikki merkittävät poikkeamat, 5 vähäistä poikkeamaa, 3 väärän positiivisen havainnon luokitteluesimerkkiä | Sisällytä poikkeamat, joissa on henkilötietoja, asiakasvaikutus tai rajat ylittävä relevanssi |
| Varmuuskopioiden palautus | Kvartaalin aikana tehdyt varmuuskopiointitestit | Kaikki kriittisten järjestelmien testit, 3 ei-kriittistä järjestelmää | Sisällytä järjestelmät, jotka tukevat kriittisiä tai tärkeitä toimintoja |
| Muutoksenhallinta | Kvartaalin tuotantoympäristön muutokset | 15 muutosta, mukaan lukien hätämuutokset | Sisällytä muutokset, jotka vaikuttavat todennukseen, lokitukseen, salaukseen tai asiakastietoihin |
| Tietoturvakoulutus | Jakson aikana aktiiviset työntekijät ja urakoitsijat | 20 käyttäjää eri osastoilta | Sisällytä johtoelinten jäsenet ja etuoikeutetut tekniset roolit |
DORA-vaikutteisissa ympäristöissä testausnäyttö ansaitsee erityishuomion. DORA edellyttää finanssialan toimijoilta digitaalisen operatiivisen häiriönsietokyvyn testausta sekä valituilta toimijoilta kehittyneempää testausta, kuten uhkalähtöistä penetraatiotestausta vähintään kolmen vuoden välein. Auditointiotosi tulisi sisältää testiraporttien lisäksi näyttöä siitä, että havainnot on priorisoitu, korjattu ja testattu uudelleen.
Käytännön auditointiesimerkki: ICT-kolmannen osapuolen riski
Toimittajaturvallisuus on usein nopein tapa paljastaa kuilu dokumentaation ja operatiivisen todellisuuden välillä. DORA Articles 28 to 30 edellyttävät ICT-kolmannen osapuolen riskienhallintaa, sopimussisältöä ja tietorekistereitä. NIS2 Article 21 edellyttää toimitusketjun turvallisuutta, jossa huomioidaan suorien toimittajien haavoittuvuudet ja käytännöt.
Q2-auditointia varten Sarah ottaa otokseen viisi kriittistä toimittajaa, kolme viimeisten kuuden kuukauden aikana käyttöönotettua uutta toimittajaa ja kaksi äskettäin uusittujen sopimusten toimittajaa. Auditoija haastattelee hankintaa, lakiasioita, palveluomistajia ja tietoturvakontrollien omistajia.
| DORA- tai NIS2-vaatimus | ISO 27001:2022 -kontrolliankkuri | Auditointikysymys | Kerättävä näyttö |
|---|---|---|---|
| DORA Article 28, ICT-kolmannen osapuolen rekisteri | A.5.19 Tietoturvallisuus toimittajasuhteissa | Onko ICT-kolmannen osapuolen järjestelyistä täydellinen ja ajantasainen rekisteri? | Ajantasainen toimittajarekisteri ja otantaan valittujen kriittisten toimittajien tallenteet |
| DORA Article 28, sopimusta edeltävä riskien arviointi | A.5.19 Tietoturvallisuus toimittajasuhteissa | Tehtiinkö huolellisuusarviointi ennen toimittajasopimusten allekirjoittamista tai uusimista? | Huolellisuusarviointiraportit, riskien arvioinnit ja hyväksymiskirjaukset |
| DORA Article 30, sopimussisältö | A.5.20 Tietoturvallisuuden huomioiminen toimittajasopimuksissa | Sisältävätkö sopimukset tarvittaessa turvallisuustoimenpiteet, tarkastusoikeudet, poikkeamatilanteiden tuen ja palvelun päättämisen tuen? | Sopimukset, liitteet, tietoturvaliitteet ja lakiasioiden katselmointimerkinnät |
| NIS2 Article 21, toimitusketjun turvallisuus | A.5.21 Tietoturvallisuuden hallinta ICT-toimitusketjussa | Ymmärretäänkö toimittajien tietoturvakäytännöt, alihankinta ja palveluriippuvuudet? | Toimittajakyselyt, alihankkijailmoitukset ja riippuvuuskartat |
| Jatkuva toimittajaseuranta | A.5.22 Toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta | Katselmoidaanko toimittajan suorituskykyä ja tietoturvaa ajan kuluessa? | QBR-pöytäkirjat, SLA-raportit, auditointiraportit ja vuosikatselmointitallenteet |
Tämä taulukko tekee muutakin kuin ohjaa näytön keräämistä. Se osoittaa, että organisaatio on kääntänyt sääntelytekstin ISO-yhteensopiviksi auditointikriteereiksi ja konkreettiseksi näytöksi.
Havainnot: kirjoita ne niin, että johto voi toimia
Auditointihavainnon ei pidä kuulostaa epämääräiseltä valitukselta. Sen on oltava riittävän rakenteinen, jotta johto ymmärtää riskin, osoittaa omistajuuden ja hyväksyy korjaavat toimenpiteet.
Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille toteaa:
Kaikki auditointihavainnot on dokumentoitava riskiluokituksineen ja ehdotettuine toimenpiteineen.
Kohdasta ‘Hallinnointivaatimukset’, politiikan kohta 5.4.1.
Suurorganisaatioille tarkoitettu Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka lisää korjaavien toimenpiteiden kurinalaisuuden:
Kaikista havainnoista on laadittava dokumentoitu CAPA, joka sisältää:
Kohdasta ‘Politiikan toteutusvaatimukset’, politiikan kohta 6.2.1.
Zenith Blueprint, Step 27, suosittelee havaintojen luokittelua merkittäviksi poikkeamiksi, vähäisiksi poikkeamiksi tai huomioiksi ja sen jälkeen juurisyyanalyysin tekemistä. Merkittävä poikkeama osoittaa vakavaa aukkoa tai järjestelmällistä epäonnistumista. Vähäinen poikkeama on yksittäinen poikkeama muuten vaatimustenmukaisessa prosessissa. Huomio on parantamismahdollisuus.
Vahva havainto sisältää:
- Vaatimuksen tai kontrolliodotuksen.
- Havaitun tilan.
- Otantaan perustuvan näytön.
- Riskin ja liiketoimintavaikutuksen.
- Sääntelyrelevanssin.
- Luokittelun ja riskiluokituksen.
- Juurisyyn.
- Korjaavan toimenpiteen omistajan ja määräpäivän.
Esimerkkihavainto:
Havainto NC-2026-07, vähäinen poikkeama, toimittajaturvallisuuden katselmoinnin viive
Vaatimus: Kriittisten ICT-palveluntarjoajien toimittajaturvallisuuden katselmoinnit on tehtävä vähintään vuosittain, mikä tukee ISO 27001:n toimittajakontrolleja, NIS2:n toimitusketjuodotuksia ja DORA:n ICT-kolmannen osapuolen riskivelvoitteita.
Tila: Kahdelta kahdestatoista kriittisestä ICT-toimittajasta puuttui vaadittuun päivämäärään mennessä valmistunut vuoden 2026 tietoturvakatselmointi.
Näyttö: Toimittajarekisterin vienti 15. kesäkuuta 2026, toimittajakatselmusten seurantataulukko, haastattelu hankintavastaavan kanssa ja kaksi puuttuvaa katselmointitallennetta.
Riski: Viivästynyt toimittajakatselmointi voi estää haavoittuvuuksien, alihankintamuutosten, poikkeamatilanteiden tuen puutteiden tai kriittisiin palveluihin vaikuttavien sopimuspuutteiden oikea-aikaisen tunnistamisen.
Juurisyy: Hankinta ei saanut automaattista ilmoitusta toimittajakatselmointien määräpäivien lähestyessä, eikä DORA:an liittyvän toimittajanäytön omistajuutta ollut osoitettu.
Korjaava toimenpide: Määritä automaattiset katselmointimuistutukset, nimeä kontrollien omistajat kaikille kriittisille ICT-toimittajille, saata myöhässä olevat katselmoinnit päätökseen 31. heinäkuuta 2026 mennessä ja tee neljännesvuosittaiset otantatarkastukset.
Juurisyyanalyysissa “5 Whys” -tekniikka on hyödyllinen. Jos sopimusta edeltävä arviointi jäi tekemättä, todellinen syy ei välttämättä ole yksittäinen virhe. Syy voi olla se, että hankinnan työnkulku salli vähäarvoisten ICT-sopimusten ohittaa tietoturvakatselmoinnin, vaikka DORA- ja NIS2-odotukset määräytyvät riskin ja riippuvuuden eivätkä pelkästään hankinnan arvon perusteella.
Vuoden 2026 näyttökalenteri
Vuoden 2026 näyttökalenteri muuttaa sisäisen auditoinnin operatiiviseksi rytmiksi. Se jakaa näytön tuottamisen koko vuodelle ja välttää vuoden lopun kiireen.
Clarysecin Tietoturvapolitiikka edellyttää hallinnointikatselmuksessa seuraavien käsittelyä:
Tietoturvan keskeisten suorituskykymittareiden (KPI), poikkeamien, auditointihavaintojen ja riskin tilan katselmointi
Kohdasta ‘Hallinnointivaatimukset’, politiikan kohta 5.3.2.
Näyttöä ei kerätä vain auditoijia varten. Se ohjaa päätöksiä riskeistä, budjetista, resursseista, toimittajista, työkaluista, koulutuksesta ja korjaavista toimenpiteistä.
| Kuukausi | Auditoinnin ja näytön fokus | Keskeiset näyttötuotokset |
|---|---|---|
| Tammikuu | Vahvista sääntelyn soveltamisala, ISMS:n soveltamisala ja vuoden 2026 auditointisuunnitelma | Hyväksytty auditointisuunnitelma, ISMS:n soveltamisalan katselmointi, NIS2- ja DORA-soveltuvuusarviointi, lakirekisterin päivitys |
| Helmikuu | Hallinnointi, riskinottohalukkuus ja johtoelimen koulutus | Hallituksen pöytäkirjat, koulutussuoritustiedot, riskikriteerit, päivitetty riskirekisteri |
| Maaliskuu | Omaisuus-, tieto- ja riippuvuusinventaario | CMDB-vienti, tietovirtojen kartat, kriittisten palvelujen luettelo, ICT-toimittajien yhteyskartta |
| Huhtikuu | Pääsynhallinta- ja MFA-auditointi | Käyttöoikeuksien katselmointien tallenteet, etuoikeutetun pääsyn otos, MFA-kattavuusraportti, poistuvien käyttäjien testaus |
| Toukokuu | Haavoittuvuudet, paikkaus ja turvallinen muutoksenhallinta | Haavoittuvuusmittarit, korjaavien toimenpiteiden näyttö, muutostikettiotos, poikkeushyväksynnät |
| Kesäkuu | Toimittaja- ja pilvipalvelujen hallinnointi | Toimittajien huolellisuusarvioinnin otos, sopimuslausekkeiden katselmointi, tarkastusoikeudet, exit-suunnitelmat, keskittymäriskiä koskevat merkinnät |
| Heinäkuu | Poikkeamien hallinta ja raportointiharjoitus | Poikkeamasimulaatio, vakavuusluokitus, NIS2-raportointityönkulun testi, DORA-poikkeamien eskalointitesti |
| Elokuu | Lokitus, seuranta ja havaitseminen | SIEM-käyttötapaukset, hälytysten viritys, seurannan kattavuus, eskalointiotanta |
| Syyskuu | Varmuuskopiointi, palautus ja liiketoiminnan jatkuvuus | Varmuuskopiointitestien tallenteet, RTO- ja RPO-näyttö, jatkuvuusharjoitus, kriisiviestintätesti |
| Lokakuu | Turvallinen kehittäminen ja sovellusturvallisuus | SDLC-näyttö, koodikatselmointiotos, tietoturvatestauksen tulokset, ulkoistetun kehittämisen katselmointi |
| Marraskuu | Täysi sisäinen ISMS-auditointi ja vaatimustenmukaisuuskehysten välinen katselmointi | Sisäisen auditoinnin raportti, havaintorekisteri, NIS2- ja DORA-kartoitus, GDPR-osoitusvelvollisuuden näyttö |
| Joulukuu | Johdon katselmointi ja korjaavien toimenpiteiden sulkeminen | Johdon katselmuksen pöytäkirjat, CAPA-tila, jäännösriskin hyväksyntä, vuoden 2027 auditointisuunnitelman syötteet |
Tämä kalenteri antaa tarkastusvaliokunnalle ennakoivan varmennussuunnitelman ja kontrollien omistajille aikaa tuottaa näyttöä normaalin toiminnan kautta.
ISO 27002:2022 -selkäranka: 5.31, 5.35 ja 5.36
Zenith Controls on Clarysecin vaatimustenmukaisuuskehysten välinen opas. Se kartoittaa ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -kontrollialueet muihin standardeihin, säädöksiin, auditointiodotuksiin ja näyttömalleihin. Se on erityisen hyödyllinen sisäisen katselmoinnin, lakisääteisten velvoitteiden ja politiikkojen noudattamisen yhdistämisessä.
Kolme ISO/IEC 27002:2022 -kontrollialuetta muodostavat yhtenäisen sisäisen auditoinnin ohjelman selkärangan:
| Zenith Controlsissa korostettu ISO 27002:2022 -alue | Auditointikysymys | NIS2- ja DORA-arvo |
|---|---|---|
| 5.31 Lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset vaatimukset | Tiedämmekö, mitkä velvoitteet koskevat meitä, ja onko ne kartoitettu kontrolleihin ja näyttöön? | Tukee NIS2-soveltuvuutta, DORA:n ICT-velvoitteita, asiakassopimuksia ja GDPR:n osoitusvelvollisuutta |
| 5.35 Tietoturvallisuuden riippumaton katselmointi | Ovatko katselmoinnit objektiivisia, suunniteltuja, pätevien henkilöiden tekemiä ja johtavatko ne toimenpiteisiin? | Tukee kyberturvallisuustoimenpiteiden varmennusta, ICT-häiriönsietokyvyn testausta ja johdon valvontaa |
| 5.36 Tietoturvallisuutta koskevien politiikkojen, sääntöjen ja standardien noudattaminen | Noudatetaanko sisäisiä sääntöjä käytännössä ja seurataanko niitä jatkuvasti? | Tukee politiikan soveltamista, kyberhygieniaa, pääsynhallintaa, valmiutta poikkeamatilanteisiin ja korjaavia toimenpiteitä |
Kontrolli 5.35 on varmennuksen kulmakivi, koska se validoi, katselmoidaanko ISMS:ää riippumattomasti. Kontrolli 5.36 vahvistaa, että politiikkoja ei vain hyväksytä, vaan niitä myös noudatetaan käytännössä. Kontrolli 5.31 yhdistää ISMS:n lakisääteisiin, sääntelyyn liittyviin ja sopimusperusteisiin velvoitteisiin, mukaan lukien NIS2, DORA, GDPR ja asiakkaiden tietoturvavaatimukset.
Vaatimustenmukaisuuskehysten välinen kartoitus: yksi auditointi, monta varmennusnäkökulmaa
Kypsän sisäisen auditoinnin työpaperin tulee osoittaa nimenomaisesti, miten yksi näyttöerä tukee useita varmennusodotuksia.
| Auditointinäyttö | ISO 27001 -varmennus | NIS2-relevanssi | DORA-relevanssi | GDPR-, NIST- ja COBIT-relevanssi |
|---|---|---|---|---|
| Laki- ja sääntelyrekisteri | Toimintaympäristö ja vaatimustenmukaisuusvelvoitteet | Soveltamisala, toimijan asema, Article 21 -ajurit | Sektorikohtaiset ICT-häiriönsietokyvyn velvoitteet | GDPR:n osoitusvelvollisuus, NIST CSF GOVERN, COBIT:n ulkoinen vaatimustenmukaisuus |
| Riskirekisteri ja riskienkäsittelysuunnitelma | Riskien arviointi, käsittely, soveltuvuuslausunto | Asianmukaiset ja oikeasuhtaiset toimenpiteet | ICT-riskien hallinnan viitekehys ja riskinsietokyky | NIST-riskienhallinta, COBIT-riskien optimointi |
| Poikkeamien pöytäharjoitusraportti | Valmius poikkeamatilanteisiin ja opit | Raportointityönkulun valmius | Luokittelu, eskalointi, raportointi ja juurisyy | GDPR-loukkausvalmius, NIST CSF RESPOND, COBIT:n hallitut poikkeamat |
| Toimittajien huolellisuusarvioinnin tiedosto | Toimittajasuhde ja ICT-toimitusketju | Toimittajien haavoittuvuudet ja käytännöt | ICT-kolmannen osapuolen rekisteri, huolellisuusarviointi, exit-suunnittelu | NIST C-SCRM, COBIT-toimittajahallinto |
| Varmuuskopion palautustesti | ICT-valmius ja jatkuvuus | Varmuuskopiointi, katastrofipalautus, kriisinhallinta | Palautumistavoitteet, palautus ja eheystarkastukset | GDPR:n saatavuus, NIST CSF RECOVER, COBIT-jatkuvuus |
| Käyttöoikeuksien katselmointi | Pääsynhallinta ja henkilöstöturvallisuus | Pääsynhallinta- ja MFA-odotukset | Vähimpien oikeuksien periaate ja vahva tunnistautuminen | GDPR:n eheys ja luottamuksellisuus, NIST CSF PROTECT |
Tämän ansiosta tietoturvajohtaja voi sanoa hallitukselle: “Heinäkuun poikkeama-auditointimme tuotti näyttöä ISO 27001:lle, NIS2:lle, DORA-asiakasvarmennukselle, GDPR-loukkausvalmiudelle, NIST CSF -reagointituloksille ja COBIT:n poikkeamien hallinnoinnille.”
Johdon katselmointi: missä auditoinnista tulee vastuun osoittamista
Sisäisellä auditoinnilla on vain vähän arvoa, jos havainnot eivät saavuta johtoa. ISO 27001:n johdon katselmointi tarjoaa mekanismin, ja NIS2 sekä DORA tekevät hallinnointiodotuksesta nimenomaisen.
Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille edellyttää:
Auditointihavainnot ja tilapäivitykset on sisällytettävä ISMS:n johdon katselmointiprosessiin.
Kohdasta ‘Hallinnointivaatimukset’, politiikan kohta 5.4.3.
Se toteaa myös:
Toimitusjohtajan on hyväksyttävä korjaavien toimenpiteiden suunnitelma ja seurattava sen toteutusta.
Kohdasta ‘Hallinnointivaatimukset’, politiikan kohta 5.4.2.
Johdon katselmoinnin tulisi vastata seuraaviin kysymyksiin:
- Ovatko NIS2-, DORA-, GDPR- ja sopimusvelvoitteet edelleen oikein kuvattuina ISMS:n soveltamisalassa?
- Auditoidaanko korkean riskin kontrolleja riittävän usein?
- Mitkä havainnot osoittavat järjestelmätason heikkoutta yksittäisen virheen sijaan?
- Ovatko korjaavat toimenpiteet myöhässä?
- Hyväksyvätkö riskinomistajat jäännösriskin tietoisesti?
- Onko toimittajille, poikkeamien ilmoittamiselle, jatkuvuudelle ja testaukselle riittävät resurssit?
- Viittaavatko auditointitrendit politiikka-, työkalu-, budjetti- tai koulutusmuutosten tarpeeseen?
Jos näitä vastauksia ei dokumentoida, organisaatiolla voi olla näyttöä toiminnasta mutta ei näyttöä hallinnoinnista.
Yleiset sudenkuopat, joita vuonna 2026 tulee välttää
Yleisin epäonnistuminen on käsitellä ISO 27001:n sisäistä auditointia erillään sääntelyvarmennuksesta. Se luo päällekkäisyyttä ja katvealueita.
Muita sudenkuoppia ovat:
- Soveltamisala sulkee pois kriittiset toimittajat, pilvialustat tai ulkoistetut SOC-palvelut.
- NIS2:n tai DORA:n soveltuvuutta ei ole dokumentoitu lakirekisteriin.
- Johto ei ole hyväksynyt auditointisuunnitelmaa.
- Otanta tehdään, mutta sitä ei dokumentoida.
- Sisäiset auditoijat katselmoivat omaa työtään ilman lieventäviä toimenpiteitä.
- Havainnot kuvaavat oireita mutta eivät juurisyitä.
- Korjaavat toimenpiteet päivittävät asiakirjoja mutta eivät korjaa prosesseja.
- Johdon katselmointi saa auditointitulokset mutta ei tee päätöksiä.
- Poikkeamaharjoitukset testaavat teknistä reagointia mutta eivät sääntelyilmoituksia.
- Toimittaja-auditoinnit katselmoivat kyselylomakkeita mutta eivät sopimuksia, exit-suunnitelmia tai keskittymäriskiä.
- Varmuuskopiointinäyttö osoittaa onnistuneita ajoja mutta ei palautuksen eheyttä.
- Käyttöoikeuksien katselmointeja tehdään, mutta poikkeuksia ei seurata sulkemiseen asti.
Kukin sudenkuoppa voi muuttua vähäiseksi tai merkittäväksi poikkeamaksi vakavuuden ja järjestelmätason vaikutuksen mukaan. Vielä tärkeämpää on, että kukin heikentää organisaation kykyä osoittaa häiriönsietokykyä NIS2:n, DORA:n ja asiakkaiden tarkastelun alla.
Muuta vuoden 2026 auditointisuunnitelmasi näyttöä tuottavaksi mekanismiksi
Jos sisäisen auditoinnin ohjelmasi on edelleen yksittäinen vuosittainen tapahtuma, nyt on aika suunnitella se uudelleen.
Aloita johdon hyväksymällä auditointisuunnitelmalla. Määritä ISMS:n soveltamisala todellisten palvelujen, säänneltyjen velvoitteiden ja kolmansien osapuolten riippuvuuksien ympärille. Rakenna riskiperusteinen auditointikokonaisuus. Dokumentoi otanta. Luokittele havainnot johdonmukaisesti. Käytä juurisyyanalyysiä. Seuraa CAPA-toimenpiteitä. Vie tulokset johdon katselmukseen. Ylläpidä kuukausittaista näyttökalenteria.
Clarysec voi auttaa etenemään nopeammin seuraavilla:
- Zenith Blueprint: auditoijan 30 askeleen tiekartta auditoinnin suunnitteluun, toteutukseen, havaintoihin, johdon katselmointiin ja jatkuvaan parantamiseen.
- Zenith Controls: vaatimustenmukaisuuskehysten välinen opas ISO 27001 -varmennuksen kartoittamiseen NIS2-, DORA-, GDPR-, NIST CSF- ja COBIT-odotuksiin.
- Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka ja Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille hallinnointivalmiiseen auditoinnin suunnitteluun ja havaintojen hallintaan.
- Tietoturvapolitiikka KPI-mittareiden, poikkeamien, auditointihavaintojen ja riskitilan katselmointiin johdon tasolla.
Valitse yksi korkean riskin alue, kuten poikkeamien ilmoittaminen tai ICT-toimittajien hallinnointi, ja toteuta kohdennettu sisäinen auditointi Clarysecin soveltamisalan, otannan ja havaintorakenteen avulla. Yhden syklin aikana tiedät, onko näyttösi valmis auditointia varten, toimivatko kontrollisi ja onko johtoelimellä tarvittavat tiedot kyberriskin hallinnointiin.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
