DORA:n ICT-riskinottohalukkuus: opas hallituksen hyväksyntään vuonna 2026

Kello on 08.15 tiistaiaamuna, ja keskisuuren maksuteknologiayhtiön tietoturvajohtaja seisoo hallituksen kokoushuoneen ulkopuolella tabletti kädessään. Auki on kolme asiakirjaa.

Ensimmäinen on ICT-riskirekisteri. Siinä on 137 riviä, värikoodatut arviot ja useita korkeita riskejä, jotka liittyvät pilvipalvelujen keskittymiseen, etuoikeutettuihin käyttöoikeuksiin, kiristyshaittaohjelmista palautumiseen, asiakastietojen altistumiseen ja toimittajan tietoturvapoikkeamiin reagointiin. Toinen on DORA-valmiuden seurantataulukko. Sen mukaan yhtiöllä on politiikat, poikkeamamenettelyt, kolmansien osapuolten rekisterit ja häiriönsietokyvyn testaussuunnitelmat. Kolmas on hallitukselle laadittu aineisto viranomaistapaamista varten.

Puheenjohtajalla on yksi kysymys, eikä se ole tekninen:

”Minkä tason ICT-riskin olemme tosiasiassa sopineet hyväksyvämme?”

Huone hiljenee, koska yhtiöllä on riskien arviointeja, mutta ei hallituksen hyväksymää ICT-riskinottohalukkuutta. Vaikutusarvioita on, mutta mitattavia riskinsietorajoja ei. Eskalointikokouksia järjestetään, mutta muodollista herätettä ei ole määritetty sille, milloin kyberriskistä tulee johtoelimen päätösasia. Jäännösriskejä on hyväksytty, mutta osa niistä on perusteltu ”liiketoimintapäätöksinä” ilman selkeää yhteyttä riskikriteereihin, GDPR Article 32:n suhteellisuusvaatimukseen, DORA:n riskinsietoa koskeviin odotuksiin tai NIS2:n mukaiseen johdon vastuuseen.

Tämä puute näkyy vuonna 2026 yhä selvemmin. DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se edellyttää finanssialan toimijoilta ICT-riskejä koskevan hallinnointi- ja valvontakehyksen ylläpitämistä. Tähän sisältyvät johtoelimen vastuu ICT-riskien hallinnan viitekehyksestä, digitaalisen operatiivisen häiriönsietokyvyn strategiasta ja ICT-riskinsietokyvystä. NIS2 ohjaa johtoelimiä hyväksymään kyberturvallisuusriskien hallintatoimenpiteet ja valvomaan niiden toteutusta. GDPR Article 32 edellyttää riskiin perustuvia asianmukaisia teknisiä ja organisatorisia turvallisuustoimenpiteitä. ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän mekanismin: toimintaympäristön, sidosryhmät, riskikriteerit, riskienkäsittelysuunnitelmat, dokumentoidun tiedon ja johdon katselmoinnin.

Puuttuva silta on ICT-riskinottohalukkuutta ja riskinsietoa koskeva lausuma, jonka hallitus voi ymmärtää, hyväksyä, haastaa ja ottaa käyttöön.

Tämä opas selittää, miten silta rakennetaan Clarysecin Zenith Blueprint: auditoijan 30-vaiheinen tiekartta -mallin, Clarysecin Riskienhallintapolitiikan, Clarysecin Riskienhallintapolitiikka-sme:n ja Zenith Controls: vaatimustenmukaisuuden ristikkäisopas avulla.

Miksi riskirekisterit eivät ole riskinottohalukkuutta

Monet organisaatiot sekoittavat riskirekisterin riskien hallinnointiin. Riskirekisteri kertoo, mitä riskejä on olemassa, miten ne on arvioitu, kuka ne omistaa ja mitä käsittelyä niille suunnitellaan. Se ei automaattisesti vastaa hallitustason kysymyksiin, joita DORA, NIS2, GDPR ja ISO/IEC 27001:2022 edellyttävät johdon käsittelevän.

Kypsä ICT-riskinottohalukkuutta koskeva lausuma vastaa esimerkiksi seuraaviin kysymyksiin:

• Mitkä ICT-riskit eivät ole hyväksyttäviä kustannuksista riippumatta?
• Kuinka pitkän operatiivisen käyttökatkon liiketoiminta voi sietää kriittisessä tai tärkeässä toiminnossa?
• Mikä tietojen menetyksen tai tietojen eheyden vaarantumisen taso ylittää riskinottohalukkuuden?
• Millainen kolmannen osapuolen keskittymäriski edellyttää hallituksen huomiota?
• Kuka saa hyväksyä ICT-jäännösriskin ja millä tasolla?
• Milloin riski on eskaloitava ylimmälle johdolle tai johtoelimelle?
• Miten lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset sisällytetään riskikriteereihin?

DORA:n näkökulmasta tämä ei ole vapaaehtoista hallinnollista viimeistelyä. Article 5 edellyttää, että johtoelin määrittää, hyväksyy ja valvoo ICT-riskien hallinnan viitekehystä ja vastaa siitä, mukaan lukien digitaalisen operatiivisen häiriönsietokyvyn strategia ja ICT-riskinsietokyky. Article 6 edellyttää dokumentoitua ICT-riskien hallinnan viitekehystä, vuosittaista katselmointia muilta kuin mikroyrityksiltä, sisäistä tarkastusta, kriittisten auditointihavaintojen korjaamista sekä digitaalisen operatiivisen häiriönsietokyvyn strategiaa, joka kattaa ICT-tavoitteet, riskinsietokyvyn, vaikutustoleranssin, arkkitehtuurin, testauksen ja poikkeamaviestinnän strategian.

NIS2 lisää rinnakkaisen vastuumallin. Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden johtoelimet hyväksyvät kyberturvallisuusriskien hallintatoimenpiteet, valvovat niiden toteutusta ja saavat koulutusta. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, jotka perustuvat kaikki vaaratekijät huomioivaan lähestymistapaan. Näihin kuuluvat riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen kehittäminen, kontrollien tehokkuus, koulutus, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta ja MFA tarvittaessa.

Finanssialan toimijoille DORA on toimialakohtainen unionin säädös, jossa sovelletaan päällekkäisiä NIS2-velvoitteita. Käytännössä DORA yleensä syrjäyttää päällekkäiset NIS2:n riskienhallinta- ja poikkeamaraportointivaatimukset sen soveltamisalaan kuuluville finanssialan toimijoille, mutta NIS2 on edelleen tärkeä koordinoinnin sekä DORA:n välittömien finanssialan toimijoita koskevien velvoitteiden ulkopuolisten palveluntarjoajien kannalta. SaaS-, pilvi-, hallinnoitujen palvelujen ja hallinnoidun tietoturvan palveluntarjoajiin NIS2 voi soveltua suoraan, jos soveltamisalan edellytykset täyttyvät.

Tästä syystä hallituksen hyväksymä ICT-riskinottohalukkuus ei ole enää finanssiriskien artefakti. Se on kyberturvallisuuden hallinnointikontrolli.

Käytä ISO/IEC 27001:2022 -standardia käyttöjärjestelmänä

DORA ja NIS2 kertovat johdolle, mitä on hallinnoitava. ISO/IEC 27001:2022 antaa organisaatioille käytännön käyttöjärjestelmän siihen, miten hallinnointi toteutetaan.

ISO/IEC 27001:2022 Clauses 4.1 to 4.4 edellyttävät, että organisaatio määrittää toimintaympäristön, sidosryhmät, vaatimukset, ISMS:n soveltamisalan ja ISMS-prosessit. Tämä on olennaista, koska DORA, NIS2, GDPR, sopimukset, valvontaviranomaisten odotukset, asiakkaat, pilvipalveluntarjoajat ja ulkoistusjärjestelyt muuttuvat kaikki vaatimuksiksi, jotka vaikuttavat riskikriteereihin.

Clauses 5.1 to 5.3 edellyttävät johdon sitoutumista, politiikkojen yhdenmukaisuutta, resursseja, vastuita ja ISMS:n suorituskyvyn raportointia ylimmälle johdolle. Clauses 6.1.1 to 6.1.3 edellyttävät riskiperusteista suunnittelua, dokumentoitua riskien arviointiprosessia, riskin hyväksyntäkriteerejä, yhdenmukaisia arviointikriteerejä, riskinomistajia, vertailua riskikriteereihin, riskienkäsittelysuunnittelua, soveltuvuuslausuntoa ja jäännösriskin hyväksyntää.

Tämä on perusta DORA:n mukaiselle ICT-riskinsietokyvylle.

Riskienhallinnan vaiheessa Zenith Blueprint -mallin Step 10 ohjeistaa organisaatioita määrittämään riskikriteerit ennen riskien arviointia:

”Riskikriteerit ovat säännöt ja vertailutasot, joiden avulla organisaatiosi arvioi kunkin riskin merkittävyyttä. Kun nämä kriteerit määritetään etukäteen, kaikki puhuvat samaa riskikieltä.”

Sama vaihe varoittaa, että sääntelyvaikutus on sisällytettävä riskimääritelmiin:

”Riski, joka voi johtaa sovellettavien lakien (GDPR jne.) noudattamatta jättämiseen, ei ole hyväksyttävä ja se on lievennettävä.”

Zenith Blueprint antaa myös käytännön ohjeita vaikutusasteikon määrittämiseen:

”Vaikutusta määritettäessä tasot kannattaa suhteuttaa omaan liiketoimintasi mittakaavaan. Esimerkiksi ’merkittävä taloudellinen vaikutus = tappio > 100 000 $’ (mukauta omaan kontekstiisi). Huomioi myös sääntelyvaikutus: esimerkiksi henkilötietojen tietoturvaloukkaus voi automaattisesti olla ’merkittävä’ tai ’vakava’ GDPR-sakkojen ja ilmoitusvaatimusten vuoksi, vaikka suora taloudellinen menetys olisi epäselvä. Vastaavasti jos kuulut NIS2:n soveltamisalaan (keskeiset palvelut), palvelukatkoksen aiheuttava poikkeama voi olla vähintään ’merkittävä’ oikeudellisten vaikutusten vuoksi. Sisällytä tällaiset näkökohdat määritelmiisi.”

Tämä ohjeistus ehkäisee yleistä virhettä: kyberriski arvioidaan kohtalaiseksi, koska välitön taloudellinen menetys näyttää pieneltä, vaikka oikeudelliset, operatiiviseen häiriönsietokykyyn liittyvät, rekisteröityihin kohdistuvat tai asiakasvaikutukset sivuutetaan.

Hallitukselle valmis malli erottaa neljä kerrosta:

Tämä rakenne tekee riskinottohalukkuudesta auditoitavan, koska jokainen lausuma voidaan jäljittää riskikriteereihin, kontrolleihin, näyttöön ja päätöksiin.

Hallitukselle valmis DORA:n ICT-riskinottohalukkuuslausuma

Vahva ICT-riskinottohalukkuuslausuma on riittävän lyhyt hallituksen hyväksyttäväksi, riittävän täsmällinen johdon sovellettavaksi ja riittävän mitattava auditoijien testattavaksi. Sen tulee välttää jargonia, mutta se ei saa olla epämääräinen.

Käytännöllinen ylätason lausuma voisi olla seuraava:

”Yhtiöllämme on matala riskinottohalukkuus ICT-riskeihin, jotka voivat aiheuttaa olennaista haittaa asiakkaille, häiriön kriittisissä tai tärkeissä toiminnoissa, sääntelyn alaisten tietojen luvattoman luovuttamisen tai muuttamisen, lakisääteisten velvoitteiden laiminlyönnin tai häiriönsietokyvyn menetyksen kriittisissä kolmannen osapuolen ICT-palveluissa.”

Tämän lausuman lisäksi tarvitaan mitattavat riskinsietorajat ja eskalointiherätteet.

Tämä taulukko muuttaa keskustelun. Hallitus ei enää hyväksy iskulausetta. Se hyväksyy toiminnalliset rajat saatavuudelle, luottamuksellisuudelle, eheydelle, toimittajille, haavoittuvuuksille, palautumiselle ja vaatimustenmukaisuudelle.

Clarysecin Riskienhallintapolitiikka tukee tätä hallinnointimallia. Yritystason politiikassa todetaan:

”Hyväksyy riskienhallinnan viitekehyksen ja määrittää hyväksyttävän riskinottohalukkuuden ja riskinsietorajat.”

Clause 6.2.1 tekee mittausvaatimuksesta nimenomaisen:

”Riskit on arvioitava todennäköisyyden ja vaikutuksen perusteella käyttäen vakiomuotoista riskimatriisia, jossa on selkeästi määritellyt pisteytysasteikot.”

Clause 6.3.4 luo hyväksyntäsäännön, jota auditoijat odottavat:

”Ilman käsittelyä hyväksytyt riskit on perusteltava kirjallisesti, kytkettävä organisaation riskinottohalukkuuteen ja hyväksyttävä asianmukaisella tasolla.”

Pk-yrityksille Riskienhallintapolitiikka-sme säilyttää saman hallinnointiperiaatteen kevyemmässä muodossa:

”Varmista johdon osallistuminen riskinsietokyvyn ja merkittävien riskienkäsittelysuunnitelmien hyväksymiseen.”

Se edellyttää myös korkeiden riskien eskalointia:

”Korkeat riskit on eskaloitava toimitusjohtajalle päätettäväksi.”

Tämä on suhteellisuutta käytännössä. DORA Article 4 edellyttää, että vaatimuksia sovelletaan oikeasuhtaisesti toimijan kokoon, riskiprofiiliin sekä palvelujen luonteeseen, laajuuteen ja monimutkaisuuteen nähden. ISO/IEC 27001:2022 mahdollistaa saman periaatteen soveltamisalan, toimintaympäristön, riskikriteerien ja riskienkäsittelypäätösten kautta. Hallinnointistandardi ei ole se, että jokainen organisaatio tarvitsee saman komitearakenteen. Hallinnointistandardi on se, että riskinottohalukkuus, riskinsietokyky, eskalointi ja hyväksyntä on määritetty, hyväksytty, osoitettavissa ja käytössä.

GDPR Article 32 muuttaa riskikeskustelua

GDPR Article 32 käsitellään usein teknisenä tietoturvalausekkeena. Hallinnoinnin näkökulmasta se on myös riskinottohalukkuutta koskeva lauseke.

Article 32 edellyttää, että rekisterinpitäjät ja henkilötietojen käsittelijät toteuttavat asianmukaiset tekniset ja organisatoriset toimenpiteet varmistaakseen riskiä vastaavan turvallisuustason. Tämä riskiperusteinen lähestymistapa huomioi tekniikan tason, toteuttamiskustannukset, käsittelyn luonteen, laajuuden, asiayhteyden ja tarkoitukset sekä luonnollisten henkilöiden oikeuksiin ja vapauksiin kohdistuvat riskit.

Tämä vaikuttaa ICT-riskinottohalukkuuteen kolmella tavalla.

Ensinnäkin henkilötietovaikutusta ei voida pelkistää taloudelliseksi menetykseksi. Pienen tietokannan altistumisella voi olla rajallinen suora kustannus mutta vakavia seurauksia luottamuksellisuudelle, identiteetille, petoksille, syrjinnälle tai oikeuksille. Jos mukana on erityisiin henkilötietoryhmiin kuuluvia tietoja, kuten terveys-, biometrisiä tai geneettisiä tietoja, riskinottohalukkuuden tulee olla olennaisesti matalampi.

Toiseksi käsittelyroolit on kytkettävä riskinomistajuuteen. GDPR erottaa rekisterinpitäjät ja henkilötietojen käsittelijät. DORA erottaa finanssialan toimijat ja ICT-kolmannen osapuolen palveluntarjoajat. NIS2 erottaa keskeiset ja tärkeät toimijat. ISO/IEC 27001:2022 edellyttää riskinomistajia. Kypsässä riskinottohalukkuuslausumassa on tunnistettava, kuka omistaa henkilötietoihin, ulkoistettuun käsittelyyn, kriittisiin palveluihin ja rajat ylittäviin riippuvuuksiin liittyvät riskipäätökset.

Kolmanneksi Article 32:n suhteellisuuden tulee näkyä kontrollien valinnassa. Salaus, pseudonymisointi, pääsynhallinta, varmuuskopiointi, lokitus, seuranta, tietoturvapoikkeamiin reagointi ja häiriönsietokyky eivät ole irrallisia teknisiä tehtäviä. Ne ovat käsittelytoimenpiteitä, jotka valitaan, koska riski ylitti riskinottohalukkuuden tai riskinsietorajan.

Clarysecin Riskienhallintapolitiikka yhdistää tämän nimenomaisesti:

”Article 32: Edellyttää riskiperusteista lähestymistapaa turvallisuustoimenpiteisiin, joka toteutetaan vaikutusperusteisilla riskien arvioinneilla ja hallintakeinojen valinnalla.”

Tämä on operatiivinen yhteys, jota auditoijat etsivät: Article 32 -vaatimus, riskien arviointi, riskiluokitus, riskienkäsittelysuunnitelma, kontrollien valinta, jäännösriski ja hyväksyntä.

Miten Zenith Controls tukee vaatimustenmukaisuuden ristikkäisnäyttöä

Hallituksen hyväksymä riskinottohalukkuuslausuma muuttuu vaikuttavaksi, kun se kartoitetaan kontrolleihin. Zenith Controls toimii Clarysecin vaatimustenmukaisuuden ristikkäisoppaana ja auttaa tiimejä hyödyntämään samaa näyttöä ISO/IEC 27001:2022:n, DORA:n, NIS2:n, GDPR:n, NIST CSF:n ja COBIT-tyyppisen varmentamisen välillä.

Kolme ISO/IEC 27002:2022 -kontrollialuetta ovat erityisen tärkeitä:

Tämä ei ole paperilla tehtävää kartoitusta. Se muuttaa päätöksentekoa.

Jos liiketoimintavastaava pyytää hyväksymään ylläpitäjien MFA-käyttöönoton viivästymisen, Zenith Controls auttaa tietoturvajohtajaa osoittamaan, miksi kyse ei ole vain pääsynhallintakysymyksestä. Se koskee politiikkojen hallinnointia, johdon vastuuta, lakisääteisiä ja sääntelyvaatimuksia, GDPR:n mukaista käsittelyn turvallisuutta, DORA:n ICT-riskien hallintaa, NIS2:n kyberturvallisuustoimenpiteitä, poikkeaman vaikutusta ja auditointinäyttöä.

Jos tuotetiimi haluaa lanseerata uudella EU-markkinalla uutta pilvipalvelua käyttäen, ISO/IEC 27002:2022 -kontrolli 5.31 tuo lakisääteisten ja sääntelyvaatimusten tarkastelun ISMS:n soveltamisalaan. ISO/IEC 27001:2022 Clause 4.2 edellyttää sidosryhmävaatimusten tunnistamista, mukaan lukien lakisääteiset, sääntelyyn perustuvat ja sopimusvelvoitteet. Clause 8.1 edellyttää operatiivista suunnittelua ja ohjausta, mukaan lukien ISMS:n kannalta olennaisten ulkoisesti tuotettujen prosessien, tuotteiden tai palvelujen ohjaus.

Tavoitteena on yksi riskikieli, ei erillisiä vaatimustenmukaisuuden murteita.

Hyväksyntätyönkulku: kuka päättää mistäkin

Tietoturvajohtaja voi ehdottaa ICT-riskinottohalukkuutta, mutta hallituksen tai johtoelimen on omistettava se. Tämä omistajuus tarvitsee työnkulun.

Tämä on linjassa myös NIST CSF 2.0:n kanssa. GOVERN-toiminto, erityisesti GV.RM, odottaa sovittuja riskienhallinnan tavoitteita, riskinottohalukkuutta ja riskinsietoa koskevia lausumia, yrityksen riskienhallintaan integroituja riskitoimia, määritettyjä riskivastevaihtoehtoja, viestintälinjoja sekä standardoituja menetelmiä kyberturvallisuusriskien laskemiseen, dokumentointiin, luokitteluun ja priorisointiin. GV.RR odottaa johdon vastuuta, rooleja, toimivaltuuksia ja resursseja, jotka on linjattu riskistrategiaan. GV.PO odottaa, että politiikat määritetään, viestitään, sovelletaan, katselmoidaan ja päivitetään.

COBIT 19- ja ISACA-tyyppisen varmentamisen ammattilaiset kysyvät, onko riskinottohalukkuus integroitu tiedon ja teknologian yritystason hallinnointiin vai onko se vain liite kyberpolitiikassa.

Rakenna ICT-riskinottohalukkuuden hallitusaineisto yhdessä työistunnossa

Käytännöllinen ICT-riskinottohalukkuuden työpaja voi siirtää organisaation hajanaisista rekistereistä auditoitavaan hallitusaineistoon.

Step 1: kerää oikeat lähtötiedot

Valmistele nykyinen ICT-riskirekisteri, liiketoimintavaikutusten arviointi, palautumistavoitteet, luettelo kriittisistä tai tärkeistä toiminnoista, ICT-omaisuusluettelo, ICT-palveluluettelo, toimittaja- ja pilviriippuvuusrekisteri, poikkeamien luokittelukriteerit, GDPR:n mukainen käsittelytoimien luettelo, asiaankuuluvat DPIA:t, lakisääteisten velvoitteiden rekisteri, politiikat, soveltuvuuslausunto ja olemassa oleva yritystason riskinottohalukkuuslausuma.

Tämä vastaa ISO/IEC 27001:2022 Clauses 4, 6 and 8 -vaatimuksia sekä NIST CSF -profiilimenetelmiä, jotka alkavat liiketoiminnan prioriteeteista, riskiprioriteeteista, vaatimuksista, suojatoimista ja rooleista.

Step 2: määritä vaikutusasteikot, jotka sisältävät sääntelyn

Määritä Zenith Blueprint -mallin Step 10:n avulla todennäköisyys ja vaikutus liiketoimintakielellä. Sisällytä taloudellinen menetys, operatiivinen häiriö, asiakasvaikutus, mainevahinko, lakisääteinen ja sääntelyvaikutus, rekisteröidylle aiheutuva haitta sekä kriittisen toiminnon vaikutus.

Esimerkiksi ”merkittävä” vaikutus voi sisältää pitkittyneen kriittisen palvelun katkon, vahvistetun ilmoitusvelvollisen henkilötietojen tietoturvaloukkauksen, DORA:n mukaisen poikkeamaraportointivelvoitteen laiminlyönnin tai toimittajan häiriön, joka vaikuttaa kriittiseen tai tärkeään toimintoon.

Step 3: kirjoita riskinottohalukkuus alueittain

Älä luo yhtä yleistä kyberriskinottohalukkuutta. Määritä alueet, kuten kriittisten palvelujen saatavuus, henkilötietojen luottamuksellisuus, tietojen eheys, etuoikeutetut käyttöoikeudet, kolmannen osapuolen ICT-riippuvuus, pilvipalvelujen keskittyminen, haavoittuvuuksien altistus, poikkeamien raportointivalmius, varmuuskopiointi ja palautuminen sekä turvallisen kehityksen muutosriski.

Kirjoita jokaiselle alueelle yksi riskinottohalukkuuslausuma, yksi tai useampi riskinsietoraja sekä eskalointiherätteet.

Step 4: kytke käsittely soveltuvuuslausuntoon

Zenith Blueprint -mallin Step 13 ohjeistaa organisaatioita valitsemaan riskien käsittelyvaihtoehdot: lieventäminen, välttäminen, siirtäminen tai hyväksyminen. Se korostaa myös johdon hyväksyntää:

”Ylimmän johdon tulee katselmoida ja hyväksyä riskienkäsittelypäätökset ja SoA.”

DORA:n ja NIS2:n kannalta tämä on näyttöä siitä, että johtoelin tai delegoitu johto on katselmoinut keskeiset riskit, käsittelyt ja hyväksytyn jäännösaltistuksen. GDPR:n kannalta se tukee osoitusvelvollisuutta näyttämällä, miksi valitut toimenpiteet olivat riskin kannalta asianmukaisia.

Step 5: kirjaa hyväksyntä päättymispäivällä ja ehdoilla

Jokaisessa hyväksytyssä keskitasoisessa tai korkeassa jäännösriskissä tulee olla:

• Riskin tunniste ja omistaja
• Liiketoimintaperuste
• Viittaus riskinottohalukkuuslausumaan
• Vaikutuksen kohteena oleva riskinsietoraja
• Lakisääteinen ja sääntelyanalyysi
• Korvaavat kontrollit
• Päättymis- tai katselmointipäivä
• Hyväksyjä
• Näytön sijainti
• Heräte päätöksen uudelleenavaamiselle

Riskienhallintapolitiikka-sme toteaa:

”Päätös hyväksyä korkea tai keskitasoinen riski tai lykätä sen käsittelyä on dokumentoitava riskirekisteriin. Dokumentaation on sisällettävä:”

Yritysympäristöissä tästä tulee hyväksyntätyönkulku ja riskikomitean aineisto. Pienemmissä organisaatioissa se voi olla rakenteinen riskirekisterin välilehti johdon hyväksynnällä. Tarkoitus ei ole byrokratia. Tarkoitus on puolustettavuus.

Poikkeamien riskinsieto: missä riskinottohalukkuus kohtaa kellon

Riskinottohalukkuus konkretisoituu poikkeamien aikana.

DORA Article 17 edellyttää, että finanssialan toimijat perustavat ICT:hen liittyvien poikkeamien hallintaprosessin poikkeamien havaitsemiseksi, hallitsemiseksi ja ilmoittamiseksi, kaikkien poikkeamien ja merkittävien kyberuhkien kirjaamiseksi, juurisyiden tunnistamiseksi, varhaisten varoitusindikaattorien käyttämiseksi, poikkeamien luokittelemiseksi prioriteetin, vakavuuden ja palvelun kriittisyyden perusteella, roolien osoittamiseksi, sidosryhmille viestimiseksi, vähintään merkittävien ICT:hen liittyvien poikkeamien eskaloimiseksi ylimmälle johdolle ja johtoelimelle sekä turvallisen toiminnan palauttamiseksi oikea-aikaisesti.

DORA Article 18 luokittelee poikkeamat esimerkiksi vaikutuksen kohteena olevien asiakkaiden, keston, käyttökatkon, maantieteellisen laajuuden, saatavuuteen, aitouteen, eheyteen tai luottamuksellisuuteen vaikuttavien tietojen menetysten, vaikutuksen kohteena olevien palvelujen kriittisyyden ja taloudellisen vaikutuksen perusteella. Article 19 edellyttää merkittävien ICT:hen liittyvien poikkeamien ilmoittamista toimivaltaiselle viranomaiselle sekä asiakkaiden informointia, kun heidän taloudelliset etunsa ovat vaikutuksen kohteena.

NIS2 Article 23 sisältää merkittävien poikkeamien vaiheistetun raportoinnin, mukaan lukien varhaisvaroituksen ilman aiheetonta viivytystä ja soveltuvin osin 24 tunnin kuluessa, poikkeamailmoituksen ilman aiheetonta viivytystä ja soveltuvin osin 72 tunnin kuluessa, pyydettäessä välipäivitykset sekä loppuraportin viimeistään kuukauden kuluttua poikkeamailmoituksesta. Merkittäviä poikkeamia ovat poikkeamat, jotka aiheuttavat vakavan operatiivisen häiriön, taloudellista tappiota tai olennaista aineellista tai aineetonta vahinkoa muille.

Riskinottohalukkuuslausuman tulee määrittää eskalointikynnykset ennen poikkeaman tapahtumista.

Liite A:n kontrollit, jotka koskevat poikkeamasuunnittelua, tietoturvatapahtumien arviointia, tietoturvapoikkeamiin reagointia, poikkeamista oppimista, todisteiden keräämistä, tietoturvan ylläpitämistä häiriöiden aikana ja ICT-valmiutta liiketoiminnan jatkuvuutta varten, tukevat näitä kynnysarvoja. NIST CSF:n tulokset IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-toiminnoissa tukevat samaa toimintamallia, mukaan lukien varmuuskopiot, seuranta, poikkeaman julistaminen, eskalointi, juurisyyanalyysi, sidosryhmäviestintä ja palautumisen varmentaminen.

Toimittaja- ja pilviriskinsieto, jonka hallitukset usein ohittavat

DORA tekee ICT-kolmansien osapuolten riskistä keskeisen vaatimustenmukaisuusvelvoitteen. Article 28 edellyttää, että finanssialan toimijat hallitsevat ICT-kolmansien osapuolten riskiä osana ICT-riskien hallinnan viitekehystä ja säilyttävät täyden vastuun vaatimustenmukaisuudesta. Se edellyttää ICT-kolmansien osapuolten riskistrategiaa, ICT-palveluja koskevien sopimusjärjestelyjen rekistereitä, kriittisiä tai tärkeitä toimintoja tukevien palvelujen erottelua, vuosittaista raportointia, suunnitelluista järjestelyistä ilmoittamista, sopimusta edeltäviä arviointeja, huolellisuutta, auditointi- ja tarkastusoikeuksia, irtisanomisoikeuksia ja dokumentoituja exit-strategioita.

Article 29 lisää keskittymäriskin analyysin, mukaan lukien korvaamattomuuden, useat riippuvuudet samasta tai toisiinsa liittyvistä palveluntarjoajista, alihankintariskit, kolmansien maiden alihankkijat, tietosuojavaatimusten noudattamisen, sopimusehtojen täytäntöönpanokelpoisuuden ja monimutkaiset alihankintaketjut. Article 30 edellyttää kirjallisia sopimusperusteisia oikeuksia ja velvoitteita, palvelukuvauksia, sijaintitietoja, tietoturvasuojauksia, tietojen käyttöä ja palauttamista, palvelutasoja, poikkeama-apua, yhteistyötä viranomaisten kanssa, irtisanomisoikeuksia, testattuja varautumissuunnitelmia, seurantaa ja exit-järjestelyjä.

Hallituksen hyväksymä toimittajariskinsietoa koskeva lausuma voisi olla seuraava:

”Meillä on matala riskinottohalukkuus siihen, että kriittiset tai tärkeät toiminnot ovat riippuvaisia ICT-kolmannen osapuolen palveluntarjoajasta, jos meiltä puuttuvat sopimusperusteiset auditointioikeudet, testatut exit-järjestelyt, poikkeamailmoitusvelvoitteet, palvelutasotavoitteet, tietojen palautusoikeudet tai näkyvyys olennaiseen alihankintaan.”

Tämä lause antaa hankinnalle käytännön säännön. Jos sopimus ei täytä kynnysarvoa, projektitiimi ei voi hiljaisesti hyväksyä riskiä.

Miten auditoijat testaavat ICT-riskinottohalukkuutesi

Vahva riskinottohalukkuuslausuma suunnitellaan auditointia ajatellen.

Zenith Blueprint -mallin Step 28 auditoinnin, katselmoinnin ja parantamisen vaiheessa vahvistaa johdon katselmointikerrosta. Se ohjeistaa organisaatioita keräämään syötteitä, kuten ulkoisten ja sisäisten seikkojen muutokset, ISMS:n suorituskyky, auditointitulokset, seuranta ja mittaus, poikkeamat, poikkeavuudet, parantamismahdollisuudet ja resurssitarpeet. Siinä todetaan myös, että johdon katselmoinnin on johdettava päätöksiin ja toimiin, ei pelkkiin esityksiin.

Vähintään vuosittain ja aina olennaisten muutosten yhteydessä johdon tulee katselmoida, ovatko riskinsietorajat edelleen linjassa liiketoimintamallin kanssa, ovatko poikkeamat ylittäneet riskinottohalukkuuden, pysyvätkö hyväksytyt riskit hyväksyttyjen rajojen sisällä, muuttivatko uudet DORA-, NIS2-, GDPR- tai sopimusvaatimukset perustasoa, pysyvätkö toimittajat keskittymäriskin sietorajojen sisällä ja aiheuttavatko KRI-mittarit oikea-aikaisen eskaloinnin.

Jos vastaus on ei, riskinottohalukkuuslausumaa tai kontrolleja on muutettava.

Yleiset epäonnistumismallit vuoden 2026 valmiustyössä

DORA-, NIS2-, GDPR- ja ISO/IEC 27001:2022 -hankkeissa samat heikkoudet toistuvat:

• Riskinottohalukkuus ilman kynnysarvoja: hallitus hyväksyy lausuman, mutta kukaan ei osaa sanoa, milloin se on ylittynyt.
• Kynnysarvot ilman toimivaltaa: vakavuustasot ovat olemassa, mutta riskinomistajat voivat hyväksyä poikkeuksia ilman ylimmän johdon hyväksyntää.
• Oikeudellinen riski pisteytysmallin ulkopuolella: GDPR, DORA, NIS2 ja sopimukset on lueteltu erikseen, mutta niitä ei ole sisällytetty vaikutuskriteereihin.
• Toimittajariskinsieto puuttuu hallitusaineistosta, vaikka kriittiset ICT-riippuvuudet ovat hankinnan tai IT:n tiedossa.
• Johdon katselmointi teatterina: dioja esitetään, mutta päätöksiä, toimia, resurssitarpeita ja riskien hyväksyntöjä ei dokumentoida.
• Auditointinäytön pirstaleisuus: politiikat, rekisterit, KRI-mittarit, poikkeamaraportit, toimittajakatselmukset ja hallituksen pöytäkirjat ovat eri paikoissa ilman ristiviitteitä.

Clarysecin lähestymistapa on suunniteltu poistamaan nämä aukot. Zenith Blueprint tarjoaa vaiheistetun toteutuspolun. Riskienhallintapolitiikka ja Riskienhallintapolitiikka-sme tarjoavat hallinnointilausekkeet, jotka skaalautuvat yritys- ja pk-yritysympäristöihin. Zenith Controls kartoittaa kontrollirangan tietoturvapolitiikan, johdon vastuun sekä lakisääteisten tai sääntelyvaatimusten yli, jolloin näyttöä voidaan hyödyntää uudelleen ISO/IEC 27001:2022:n, DORA:n, NIS2:n, GDPR:n, NIST CSF:n ja COBIT-tyyppisen varmentamisen välillä.

Muunna hallituksen tahtotila auditoitavaksi ICT-riskien hallinnoinniksi

Jos organisaatiollasi on riskirekisteri mutta se ei pysty osoittamaan hallituksen hyväksymää ICT-riskinottohalukkuutta, mitattavia riskinsietorajoja, eskalointiherätteitä ja muodollisia hyväksyntäsääntöjä, puute ei ole kosmeettinen. Se vaikuttaa DORA:n hallinnointiin, NIS2:n johdon vastuuseen, GDPR Article 32:n puolustettavuuteen ja ISO/IEC 27001:2022:n auditointivalmiuteen.

Käytännön seuraava askel on toteuttaa kohdennettu ICT-riskinottohalukkuuden työpaja Clarysecin työkalupakin avulla:

1. Käytä Zenith Blueprint -mallin Step 10:tä riskikriteerien ja vaikutusasteikkojen määrittämiseen.
2. Käytä Zenith Blueprint -mallin Step 13:a käsittelyvaihtoehtojen, jäännösriskin ja soveltuvuuslausunnon hyväksynnän yhdistämiseen.
3. Käytä Zenith Blueprint -mallin Step 14:ää GDPR-, NIS2- ja DORA-velvoitteiden ristiviittaamiseen.
4. Käytä Zenith Blueprint -mallin Step 28:aa riskinottohalukkuuden, KRI-mittareiden, hyväksyttyjen riskien ja resurssipäätösten tuomiseksi johdon katselmointiin.
5. Sovella Riskienhallintapolitiikkaa tai Riskienhallintapolitiikka-sme:tä hyväksyntä- ja hyväksymissääntöjen virallistamiseen.
6. Käytä Zenith Controls -opasta hallinnointikontrollien kartoittamiseen auditointinäyttöön ja vaatimustenmukaisuuden ristikkäisiin odotuksiin.

Clarysec voi auttaa muuttamaan hajanaiset riskiartefaktit hallituksen hyväksymäksi ja viranomaisvalmiiksi ICT-riskinottohalukkuuden malliksi, jota tiimisi voivat käyttää, kun seuraava pilvipalvelukatko, toimittajahäiriö, haavoittuvuuden julkistus tai henkilötietopoikkeama testaa organisaation todellisen riskinsietokyvyn.