DORA-tietorekisteri: ISO 27001 -opas

On tiistai kello 09.15. Nopeasti kasvavan fintech-yhtiön tietoturvajohtaja Sarah istuu valmiusarvioinnissa vaatimustenmukaisuuspäällikön, lakimiehen, hankintavastaavan ja pilviarkkitehdin kanssa. Ulkoinen konsultti toimii harjoituksessa DORA-valvojana.

”Kiitos esityksestä”, hän sanoo. ”Toimittakaa DORA:n 28 artiklan edellyttämä tietorekisterinne, mukaan lukien kriittisiä tai tärkeitä toimintoja tukevat ICT-sopimusjärjestelyt, alihankintaa koskeva näkyvyys, omaisuuden omistajuus sekä näyttö siitä, että rekisteriä ylläpidetään ICT-riskienhallintakehyksenne mukaisesti.”

Ensimmäinen vastaus kuulostaa varmalta: ”Meillä on toimittajaluettelo.”

Sitten kysymykset alkavat.

Mitkä toimittajat tukevat maksujen hyväksyntää? Mitkä sopimukset sisältävät auditointioikeudet, poikkeamatilanteiden tuen, tietojen sijaintia koskevat sitoumukset, irtisanomisoikeudet ja irtautumistuen? Mitkä SaaS-alustat käsittelevät asiakkaiden henkilötietoja? Mitkä pilvipalvelut tukevat kriittisiä tai tärkeitä toimintoja? Mitkä alihankkijat ovat hallinnoidun tietoturvapalveluntarjoajan taustalla? Mikä sisäinen omaisuuden omistaja hyväksyi riippuvuuden? Mitkä ISO/IEC 27001:2022 -riskienkäsittelysuunnitelman riskit on liitetty näihin palveluntarjoajiin? Mitkä soveltuvuuslausunnon kirjaukset perustelevat kontrollit?

Kello 10.30 mennessä tiimi on avannut neljä laskentataulukkoa, CMDB-viennin, SharePoint-kansion PDF-sopimuksia, tietosuojan käsittelijäluettelon, pilvilaskutusraportin ja manuaalisesti ylläpidetyn SaaS-seurannan. Mikään niistä ei täsmää.

Tämä on DORA-tietorekisterin käytännön haaste vuonna 2026. DORA-toteutus on siirtynyt vaiheesta ”tarvitsemme tiekartan” vaiheeseen ”näyttäkää näyttö”. Finanssiyhteisöille, kolmantena osapuolena oleville ICT-palveluntarjoajille, tietoturvajohtajille, sisäisille auditoijille ja vaatimustenmukaisuustiimeille rekisteri ei ole enää hallinnollinen mallipohja. Se on yhdistävä rakenne ICT-sopimusten, toimittajariskin, alihankintaketjujen, pilvipalvelujen, ICT-omaisuuserien, kriittisten toimintojen, hallinnointivastuun ja ISO/IEC 27001:2022 -näytön välillä.

Clarysecin lähestymistapa on yksinkertainen: DORA-tietorekisteriä ei tule rakentaa erilliseksi vaatimustenmukaisuusartefaktiksi. Se tulee rakentaa ISMS:n sisäiseksi eläväksi näyttökerrokseksi, jota tukevat omaisuudenhallinta, toimittajaturvallisuus, pilvipalvelujen käytön hallinnointi, lakisääteisten ja sääntelyvelvoitteiden kartoitus, auditoinnin metatiedot sekä riskien käsittelyn jäljitettävyys.

Clarysecin Zenith Controls: The Cross-Compliance Guide Zenith Controls tunnistaa kolme ISO/IEC 27001:2022:n liitteen A ankkurikontrollia erityisen olennaisiksi tässä aiheessa: A.5.9, tieto- ja muiden niihin liittyvien omaisuuserien inventaario; A.5.19, tietoturva toimittajasuhteissa; ja A.5.20, tietoturvan käsittely toimittajasopimuksissa. Nämä kontrollit eivät ole lisäpaperityötä. Ne ovat operatiivinen selkäranka, jolla osoitetaan, että rekisteri on kattava, omistettu, ajantasainen ja todennettavissa.

Mitä DORA odottaa tietorekisteriltä

DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se luo finanssisektorille ICT-häiriönsietokyvyn sääntökokonaisuuden ICT-riskien hallintaa, poikkeamien raportointia, häiriönsietokyvyn testausta, kolmansien osapuolten riskiä, sopimusjärjestelyjä, kriittisten kolmantena osapuolena olevien ICT-palveluntarjoajien valvontaa ja valvonnallista toimeenpanoa varten. Niille finanssiyhteisöille, jotka kuuluvat myös kansallisen NIS2-täytäntöönpanon piiriin, DORA toimii alakohtaisena unionin säädöksenä vastaaville kyberturvallisuuden riskienhallinta- ja poikkeamaraportointivaatimuksille.

Rekisterivelvoite kuuluu DORA:n kolmansien osapuolten ICT-riskienhallinnan kokonaisuuteen. DORA:n 28 artikla edellyttää, että finanssiyhteisöt hallitsevat kolmansien osapuolten ICT-riskiä osana ICT-riskienhallintakehystä, säilyttävät täyden vastuun vaatimusten noudattamisesta myös ICT-palveluntarjoajia käytettäessä, ylläpitävät tietorekisteriä ICT-palveluja koskevista sopimusjärjestelyistä ja erottavat kriittisiä tai tärkeitä toimintoja tukevat järjestelyt.

DORA:n 29 artikla lisää keskittymäriskiä ja alihankintariskiä koskevat näkökohdat. Näihin kuuluvat korvattavuus, useat riippuvuudet samasta tai toisiinsa kytkeytyneistä palveluntarjoajista, kolmansissa maissa tapahtuva alihankinta, maksukyvyttömyyteen liittyvät rajoitteet, tietojen palautus, tietosuojavaatimusten noudattaminen sekä pitkät tai monimutkaiset alihankintaketjut.

DORA:n 30 artikla määrittää tämän jälkeen sopimussisällön, jonka auditoijat odottavat näkevänsä. Tähän sisältyvät palvelukuvaukset, alihankintaa koskevat ehdot, tietojen käsittelypaikat, tietosuojasitoumukset, pääsy- ja palautusvelvoitteet, palvelutasot, poikkeamatilanteiden tuki, viranomaisyhteistyö, irtisanomisoikeudet, osallistuminen koulutukseen, auditointioikeudet sekä irtautumisstrategiat kriittisiä tai tärkeitä toimintoja tukeville järjestelyille.

Kypsän DORA-tietorekisterin on vastattava neljään käytännön kysymykseen.

Heikko rekisteri on laskentataulukko, jonka hankinta päivittää kerran vuodessa. Vahva rekisteri on hallittu tietoaineisto, joka yhdistää toimittajaportfolion, omaisuusluettelon, pilvirekisterin, sopimustietovaraston, tietosuojatallenteet, liiketoiminnan jatkuvuussuunnitelmat, poikkeamien toimintamallit, riskirekisterin ja ISO/IEC 27001:2022 -näytön.

Miksi ISO 27001 on nopein reitti puolustettavaan DORA-rekisteriin

ISO/IEC 27001:2022 antaa organisaatioille hallintajärjestelmärakenteen, jota DORA-näytöstä usein puuttuu. Kohdat 4.1–4.4 edellyttävät, että organisaatio määrittää toimintaympäristön, sidosryhmät, lakisääteiset, sääntelyyn liittyvät ja sopimusperusteiset velvoitteet, soveltamisalan, rajapinnat ja riippuvuudet. Juuri tähän DORA kuuluu ISMS:ssä, koska rekisteri riippuu siitä, tiedetäänkö mitkä finanssipalvelut, ICT-palveluntarjoajat, asiakkaat, viranomaiset, pilvialustat ja ulkoistetut prosessit kuuluvat soveltamisalaan.

Kohdat 5.1–5.3 edellyttävät johtajuutta, politiikkojen yhdenmukaistamista, resursseja, vastuita ja raportointia ylimmälle johdolle. Tämä on olennaista, koska DORA:n 5 artikla asettaa hallintoelimelle vastuun ICT-riskienhallintakehyksen määrittämisestä, hyväksymisestä, valvonnasta ja siitä vastuun kantamisesta, mukaan lukien kolmantena osapuolena olevien ICT-palveluntarjoajien palveluja koskevat politiikat ja raportointikanavat.

Kohdat 6.1.1–6.1.3 ovat kohta, jossa rekisteristä tulee riskiperusteinen. ISO/IEC 27001:2022 edellyttää toistettavaa riskien arviointiprosessia, riskinomistajia, todennäköisyyden ja seurausten analyysiä, riskien käsittelyä, kontrollien valintaa, soveltuvuuslausuntoa ja riskinomistajan hyväksyntää jäännösriskille. DORA-rekisteri, jota ei ole liitetty riskien käsittelyyn, jää staattiseksi luetteloksi. Rekisteri, joka on liitetty riskiskenaarioihin, kontrolleihin ja omistajiin, muodostuu auditointinäytöksi.

Kohdat 8.1–8.3 muuttavat suunnittelun hallituksi toiminnaksi. Ne tukevat dokumentoitua tietoa, operatiivista suunnittelua ja kontrollia, muutosten hallintaa, ulkoisesti tuotettujen prosessien hallintaa, suunniteltuja riskien uudelleenarviointeja, käsittelytoimien toteutusta ja näytön säilyttämistä. Tämä on kriittistä vuonna 2026, koska valvojat eivät kysy ainoastaan, oliko rekisteri olemassa tiettynä ajankohtana. He kysyvät, kirjautuvatko uudet sopimukset, muuttuneet palvelut, uudet alihankkijat, pilvimigraatiot ja irtautumistapahtumat hallinnointisykliin.

Liitteen A kontrollikerros vahvistaa saman asian. Toimittajasuhteet, toimittajasopimukset, ICT-toimitusketjun riski, toimittajapalvelujen seuranta, pilvipalvelujen hankinta ja irtautuminen, poikkeamien hallinta, liiketoiminnan jatkuvuus, lakisääteiset ja sääntelyvelvoitteet, tietosuoja, varmuuskopiot, lokitus, seuranta, kryptografia ja haavoittuvuuksien hallinta vaikuttavat kaikki rekisterin laatuun.

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint selittää omaisuusperustan Controls in Action -vaiheen Step 22:ssa:

Strategisimmassa muodossaan omaisuusluettelo toimii ISMS:n keskushermostona. Se ohjaa, miten käyttöoikeuksien myöntäminen tehdään (8.2), missä salausta on sovellettava (8.24), mitkä järjestelmät tarvitsevat varmuuskopioinnin (8.13), mitä lokeja kerätään (8.15) ja jopa miten luokittelu- ja säilytyspolitiikkoja sovelletaan (5.10, 8.10).

Tuo lainaus kiteyttää käytännön asian. Luotettavaa DORA-tietorekisteriä ei voi ylläpitää, ellei taustalla oleva omaisuusluettelo ole luotettava. Jos rekisterissä lukee ”Core Banking SaaS”, mutta omaisuusluettelo ei näytä ohjelmointirajapintoja, palvelutilejä, tietoaineistoja, lokilähteitä, salausavaimia, varmuuskopiointiriippuvuuksia ja omistajia, rekisteri on auditoinnin näkökulmasta puutteellinen.

Clarysecin tietomalli: yksi rekisteri, monta näyttönäkymää

DORA-tietorekisterin ei tule korvata toimittajarekisteriä, omaisuusrekisteriä tai pilvirekisteriä. Sen tulee yhdistää ne. Clarysec suunnittelee rekisterin yleensä päänäyttökerrokseksi, jolla on hallitut suhteet olemassa oleviin ISMS-tallenteisiin.

Vähimmäiskelpoinen malli sisältää seitsemän toisiinsa liitettyä objektia.

Tämä rakenne mahdollistaa sen, että yksi rekisteri tukee useita näyttöpyyntöjä. DORA-valvoja voi tarkastella kriittisiä tai tärkeitä toimintoja tukevia sopimusjärjestelyjä. ISO-auditoija voi jäljittää toimittajakontrollit liitteen A viittauksiin ja riskien käsittelyyn. GDPR-tarkastelija voi nähdä käsittelijät, tietoluokat, sijainnit ja tietosuojasitoumukset. NIST-painotteinen arvioija voi tarkastella toimitusketjun hallinnointia, toimittajien kriittisyyttä, sopimusvaatimuksia ja elinkaaren aikaista seurantaa.

Rekisteristä tulee enemmän kuin vastaus kysymykseen ”ketkä ovat toimittajamme?”. Siitä tulee riippuvuuskaavio.

Politiikkaperusta, joka tekee rekisteristä auditoitavan

Clarysecin politiikkakokonaisuus antaa rekisterille operatiivisen kotipaikan. Pk-yrityksille Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME alkaa selkeällä rekisterivaatimuksella:

Toimittajarekisteriä on ylläpidettävä ja päivitettävä hallinnollisen tai hankintayhteyshenkilön toimesta. Sen on sisällettävä:

Sama pk-yrityspolitiikka määrittää, että sopimusten on sisällettävä määritellyt tietoturvavelvoitteet:

Sopimuksiin on sisällytettävä pakolliset lausekkeet, jotka kattavat:

Vaikka lainatut kohdat tuovat itse politiikassa esiin kenttäluetteloita ja pakollisten lausekkeiden luokkia, toteutusviesti on suora: toimittajahallinta on dokumentoitava, vastuutettava ja vietävä sopimuksellisesti täytäntöön.

Yritysympäristöissä Clarysecin Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy on vielä lähempänä DORA:n valvontaodotuksia:

Toimittajariippuvuusrekisteri: VMO:n tulee ylläpitää ajantasaista rekisteriä kaikista kriittisistä toimittajista. Rekisteriin on sisällytettävä tiedot, kuten toimitetut palvelut/tuotteet; onko toimittaja ainoa lähde; saatavilla olevat vaihtoehtoiset toimittajat tai korvattavuus; voimassa olevat sopimusehdot; sekä arvio vaikutuksesta, jos toimittaja epäonnistuisi tai vaarantuisi. Rekisterin on tunnistettava selkeästi korkean riippuvuuden toimittajat (esim. toimittajat, joille ei ole nopeasti saatavilla olevaa vaihtoehtoa).

Tämä vastaa luontevasti DORA:n 29 artiklan keskittymä- ja korvattavuusriskiä. Jos toimittaja on ainoa lähde, tukee kriittistä toimintoa, toimii kolmannessa maassa, käyttää pitkää alihankintaketjua eikä sillä ole testattua irtautumispolkua, rekisterin ei pidä piilottaa tätä riskiä vapaamuotoiseen huomautukseen. Sen tulee merkitä riski, nimetä omistaja ja liittää se riskien käsittelyyn.

Clarysecin yritystason Third party and supplier security policy Third party and supplier security policy tekee soveltamisalan selkeäksi:

Se kattaa sekä suorat toimittajat että soveltuvin osin niiden alihankkijat ja sisältää kolmannen osapuolen ohjelmistot, infrastruktuurin, tuen ja hallinnoidut palvelut.

Tuo lause kuvaa yleistä DORA-puutetta. Monet organisaatiot kirjaavat suorat ICT-palveluntarjoajat mutta eivät dokumentoi alihankkijoita, alikäsittelijöitä, hallinnoitujen palvelujen työkalustoa, tukialustoja tai palveluun sisältyviä kolmannen osapuolen ohjelmistoja.

Sopimusnäyttö on myös tärkeää. Sama yritystason politiikka sisältää kohdan:

Oikeudet auditoida, tarkastaa ja pyytää tietoturvanäyttöä

Tämän lauseen tulisi näkyä sopimuskatselmoinnin tarkistuslistassa. Jos kriittisen ICT-palveluntarjoajan sopimuksesta puuttuvat auditointi- tai näyttöoikeudet, rekisterin tulee merkitä korjaava toimenpide.

Omaisuusnäyttö on yhtä tärkeää. Clarysecin pk-yritysten Asset Management Policy Asset Management Policy - SME toteaa:

IT-vastaavan on ylläpidettävä rakenteista omaisuusluetteloa, joka sisältää vähintään seuraavat kentät:

Yritystason Asset Management Policy Asset Management Policy toteaa vastaavasti:

Omaisuusluettelon on sisällettävä vähintään:

Rekisterin ei tarvitse kopioida jokaista omaisuuskenttää, mutta sen on viitattava omaisuusluetteloon. Jos maksujen seurantaan käytettävä SaaS tukee petosten havaitsemista, DORA-rekisterin tulee linkittyä sovellusomaisuuteen, tietoaineistoon, palvelutileihin, API-integraatioihin, lokilähteisiin ja liiketoimintavastaavaan.

Pilvipalvelut tarvitsevat oman näkymän. Clarysecin pk-yritysten Cloud Usage Policy Cloud Usage Policy - SME edellyttää:

Pilvipalvelurekisteriä on ylläpidettävä IT-palveluntarjoajan tai toimitusjohtajan toimesta. Sen on kirjattava:

Tämä on erityisen arvokasta varjo-IT:n havaitsemisessa. DORA-rekisteri, joka jättää hankinnan ulkopuolelta ostetut pilvipalvelut pois, epäonnistuu käytännön kattavuustestissä.

Lopuksi Clarysecin Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy muuttaa ristikkäisen vaatimustenmukaisuuden ISMS-vaatimukseksi:

Kaikki laki- ja sääntelyvelvoitteet on kartoitettava tiettyihin politiikkoihin, kontrolleihin ja omistajiin tietoturvallisuuden hallintajärjestelmässä (ISMS).

Tämä on silta DORA-rekisteristä ISO 27001 -näyttöön. Rekisterin ei tule näyttää vain toimittajia. Sen tulee osoittaa, mitkä politiikat, kontrollit ja omistajat täyttävät sääntelyvelvoitteen.

DORA-vaatimusten kartoitus ISO 27001:een ja Clarysec-näyttöön

Alla oleva taulukko yhdistää keskeiset rekisteriodotukset ISO/IEC 27001:2022:n liitteen A kontrolleihin ja käytännön Clarysec-näyttöartefakteihin.

Tässä kartoituksessa rekisteri lakkaa olemasta laskentataulukko ja muuttuu näyttömalliksi. Jokaisella rivillä tulee olla sopimusomistaja, toimittajaomistaja, palveluomistaja, liiketoimintavastaava ja vaatimustenmukaisuuden omistaja. Jokaisella kriittisellä suhteella tulee olla riskitietue, sopimuslausekkeiden tarkistuslista, omaisuuslinkki ja seurantatiheys.

Käytännön esimerkki: yhden ICT-sopimuksen kartoitus ISO 27001 -näyttöön

Kuvitellaan, että finanssiyhteisö käyttää pilvipohjaista petosanalytiikka-alustaa. Palvelu vastaanottaa tapahtumametatietoja, tukee reaaliaikaista petospisteytystä, integroituu maksualustaan, tallentaa pseudonymisoituja asiakastunnisteita, käyttää pilvi-infrastruktuurin alihankkijaa ja tarjoaa hallinnoitua tukea hyväksytystä kolmannen maan sijainnista.

Heikko rekisteririvi sanoo: ”Toimittaja: FraudCloud. Palvelu: petosanalytiikka. Sopimus allekirjoitettu. Kriittinen: kyllä.”

Valvontakelpoinen rekisteririvi näyttää hyvin erilaiselta.

Nyt vaatimustenmukaisuustiimi voi tuottaa johdonmukaisen näyttöpaketin. Toimittajarekisteri osoittaa, että palveluntarjoaja on olemassa ja sillä on omistaja. Omaisuusluettelo osoittaa, että sisäiset järjestelmät, ohjelmointirajapinnat, tietoaineistot ja lokit ovat tiedossa. Sopimustarkistuslista osoittaa, että pakolliset DORA-lausekkeet on katselmoitu. Riskien arviointi osoittaa, että keskittymä, alihankinta, tietosuoja ja operatiivinen häiriönsietokyky on huomioitu. Soveltuvuuslausunto näyttää, mitkä kontrollit on valittu. Seurantakatselmointi osoittaa, ettei järjestelyä unohdeta käyttöönoton jälkeen.

Zenith Blueprint, Risk Management -vaiheen Step 13, suosittelee juuri tällaista jäljitettävyyttä:

Ristiinviittaa sääntelyyn: jos tiettyjä kontrolleja on toteutettu erityisesti GDPR:n, NIS2:n tai DORA:n noudattamiseksi, voit merkitä sen joko riskirekisteriin (osana riskivaikutuksen perustelua) tai SoA-huomautuksiin.

Näin DORA-rekisteristä tulee ISO 27001 -näyttöä rinnakkaisen byrokratian sijaan.

Rekisterin laatu pettää toimittaja- ja alihankintaketjussa

Suurimmat rekisteripuutteet eivät johdu ylimmän tason toimittajien puuttumisesta. Ne johtuvat piilossa olevista riippuvuusketjuista.

Hallinnoitu tietoturvapalveluntarjoaja voi käyttää SIEM-alustaa, päätelaitteen telemetria-agenttia, tikettijärjestelmää ja offshore-triage-tiimiä. Maksunkäsittelijä voi olla riippuvainen pilvi-infrastruktuurista, identiteettipalveluista, petostietokannoista ja selvitysyhteyksistä. SaaS-palveluntarjoaja voi nojata useisiin alikäsittelijöihin analytiikassa, sähköpostissa, havainnoitavuudessa, asiakastuessa ja varmuuskopioissa.

DORA:n 29 artikla kohdistaa huomion keskittymäriskiin ja alihankintariskiin. Myös NIS2:n 21 artikla edellyttää toimitusketjun tietoturvaa suorille toimittajille ja palveluntarjoajille sekä odottaa, että toimijat ottavat huomioon kullekin suoralle toimittajalle ominaiset haavoittuvuudet, tuotteiden yleisen laadun, toimittajien kyberturvallisuuskäytännöt ja turvallisen kehittämisen menettelyt. DORA:n piiriin kuuluville finanssiyhteisöille DORA toimii alakohtaisena sääntökokonaisuutena päällekkäisille NIS2:n kyberturvallisuuden riskienhallinta- ja poikkeamaraportointivaatimuksille, mutta toimitusketjulogiikka on yhdenmukainen.

Clarysecin Zenith Blueprint, Controls in Action -vaiheen Step 23, antaa käytännön ohjeen:

Tunnista jokaisen kriittisen toimittajan osalta, käyttävätkö he alihankkijoita (alikäsittelijöitä), joilla voi olla pääsy tietoihisi tai järjestelmiisi. Dokumentoi, miten tietoturvavaatimuksesi siirretään näille osapuolille joko toimittajasi sopimusehtojen tai omien suorien lausekkeidesi kautta.

Tässä kohtaa monet organisaatiot tarvitsevat korjaavia toimenpiteitä vuonna 2026. Ennen DORA-valmiutta allekirjoitetut sopimukset eivät välttämättä sisällä alihankkijoiden läpinäkyvyyttä, auditointinäyttöoikeuksia, viranomaisyhteistyötä, poikkeamatilanteiden tukea, irtautumistukea tai sijaintisitoumuksia. Rekisterin tulee siksi sisältää sopimuksen korjaustila, kuten valmis, puute hyväksytty, uudelleenneuvottelu käynnissä tai irtautumisvaihtoehto vaaditaan.

Ristikkäinen vaatimustenmukaisuus: DORA, NIS2, GDPR ja NIST tarvitsevat saman riippuvuustotuuden

Hyvin suunniteltu DORA-tietorekisteri tukee muutakin kuin DORA:a.

NIS2:n 20 artikla tekee kyberturvallisuudesta hallintoelimen vastuun hyväksynnän, valvonnan ja koulutuksen kautta. 21 artikla edellyttää riskianalyysiä, politiikkoja, poikkeamien käsittelyä, jatkuvuutta, toimitusketjun tietoturvaa, turvallista hankintaa ja ylläpitoa, vaikuttavuuden arviointia, kyberhygieniaa, kryptografiaa, henkilöstöturvallisuutta, pääsynhallintaa, omaisuudenhallintaa ja tarvittaessa MFA:ta. Nämä osa-alueet limittyvät vahvasti ISO/IEC 27001:2022:n ja rekisterin näyttömallin kanssa.

GDPR lisää tietosuojan osoitusvelvollisuuden. Sen alueellinen soveltamisala voi ulottua EU:ssa ja EU:n ulkopuolella toimiviin organisaatioihin, jotka käsittelevät henkilötietoja EU:ssa sijaitsevien toimipaikkojen yhteydessä, tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään. GDPR:n määritelmät rekisterinpitäjästä, käsittelijästä, käsittelystä, pseudonymisoinnista ja henkilötietojen tietoturvaloukkauksesta ovat suoraan olennaisia ICT-toimittajien kartoituksessa. Jos DORA-rekisteri tunnistaa ICT-palveluntarjoajat ja alihankkijat mutta ei tunnista henkilötietojen käsittelyrooleja, tietoluokkia, sijainteja ja suojatoimia, se ei tue GDPR-näyttöä.

NIST CSF 2.0 tarjoaa toisen hyödyllisen näkökulman. Sen GOVERN-toiminto edellyttää, että organisaatiot ymmärtävät mission, sidosryhmien odotukset, riippuvuudet, lakisääteiset ja sopimusperusteiset vaatimukset, palvelut, joista muut ovat riippuvaisia, sekä palvelut, joista organisaatio itse on riippuvainen. Sen GV.SC-toimitusketjutulokset edellyttävät toimitusketjuriskien hallintaohjelmaa, määriteltyjä toimittajarooleja, integrointia yrityksen riskienhallintaan, toimittajien kriittisyyttä, sopimusvaatimuksia, huolellisuusarviointia, elinkaaren aikaista seurantaa, poikkeamien koordinointia ja suhteen jälkeistä suunnittelua.

Käytännön ristikkäisen vaatimustenmukaisuuden näkymä näyttää tältä.

Tarkoituksena ei ole luoda viittä vaatimustenmukaisuustyövirtaa. Tarkoituksena on luoda yksi näyttömalli, jota voidaan suodattaa kutakin viitekehystä varten.

Auditoijan silmin

DORA-valvoja keskittyy kattavuuteen, kriittisiin tai tärkeisiin toimintoihin, sopimusjärjestelyihin, alihankintaan, keskittymäriskiin, hallinnointiin, raportointiin ja siihen, ylläpidetäänkö rekisteriä. Hän voi pyytää otosta kriittisistä palveluntarjoajista ja odottaa näkevänsä sopimuslausekkeet, riskien arvioinnit, irtautumisstrategiat, poikkeamatilanteiden tukiehdot ja näytön johdon valvonnasta.

ISO/IEC 27001:2022 -auditoija aloittaa ISMS:n soveltamisalasta, sidosryhmistä, sääntelyvelvoitteista, riskien arvioinnista, soveltuvuuslausunnosta, operatiivisesta kontrollista ja dokumentoidusta tiedosta. Hän testaa, ylläpidetäänkö toimittajasuhteita ja omaisuusluetteloita, hallitaanko ulkoisesti tuotettuja prosesseja, laukaisevatko muutokset uudelleenarvioinnin ja tukeeko näyttö väitettyä kontrollien toteutusta.

NIST CSF 2.0 -arvioija pyytää usein nykyisiä ja tavoiteprofiileja, hallinnointiodotuksia, riippuvuuskartoitusta, toimittajien kriittisyyttä, sopimusintegraatiota, elinkaaren aikaista seurantaa ja priorisoituja parannustoimia.

COBIT 2019 -suuntautunut auditoija tarkastelee tyypillisesti hallinnointivastuuta, prosessien vastuutettavuutta, päätösoikeuksia, suorituskyvyn seurantaa, riskiraportointia ja varmennusta. Hän kysyy, onko rekisteri upotettu yrityksen hallintotapaan eikä vain vaatimustenmukaisuustoiminnon ylläpitämä.

Zenith Controls auttaa kääntämään nämä näkökulmat ankkuroimalla aiheen ISO/IEC 27001:2022:n liitteen A kontrolleihin A.5.9, A.5.19 ja A.5.20 ja käyttämällä sitten ristikkäisen vaatimustenmukaisuuden tulkintaa omaisuuserien, toimittajasuhteiden ja toimittajasopimusten liittämiseksi sääntely-, hallinnointi- ja auditointiodotuksiin. Tämä on ero lausuman ”meillä on rekisteri” ja lausuman ”voimme puolustaa rekisteriä” välillä.

Clarysecin pk-yritysten Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy - SME käsittelee myös näytön laatua:

Metatiedot (esim. kuka keräsi aineiston, milloin ja mistä järjestelmästä) on dokumentoitava.

Tämä vaatimus on pieni mutta tehokas. Vuoden 2026 näyttöpyynnössä laskentataulukko ilman keruun metatietoja on heikko. Rekisterivienti, joka näyttää lähdejärjestelmän, poimintapäivän, vastuullisen omistajan, hyväksyntätilan ja katselmointitiheyden, on vahvempi.

Yleiset DORA-tietorekisterin havainnot vuonna 2026

Yleisimmät havainnot ovat käytännönläheisiä.

Ensinnäkin rekisterin puutteellinen kattavuus. Pilvipalvelut, tukityökalut, valvonta-alustat, kehittäjätyökalut, tikettijärjestelmät ja data-analytiikka-alustat puuttuvat usein, koska hankinta ei ole luokitellut niitä ICT-palveluiksi.

Toiseksi heikko kriittisyyslogiikka. Jotkin tiimit merkitsevät toimittajat kriittisiksi kulujen, eivät liiketoimintavaikutuksen perusteella. DORA:a kiinnostaa, tukeeko ICT-palvelu kriittistä tai tärkeää toimintoa.

Kolmanneksi sopimusnäytön puutteet. Vanhemmista toimittajasopimuksista puuttuu usein DORA-valmiit lausekkeet auditointioikeuksista, poikkeamatilanteiden tuesta, alihankinnasta, viranomaisyhteistyöstä, palvelusijainneista, tietojen palautuksesta, irtisanomisesta ja irtautumistuesta.

Neljänneksi heikko omaisuuslinkitys. Rekisterit luettelevat toimittajat mutta eivät linkitä niitä sovelluksiin, tietoaineistoihin, ohjelmointirajapintoihin, identiteetteihin, lokeihin, infrastruktuuriin tai liiketoimintapalveluihin. Tämä vaikeuttaa vaikutusanalyysiä poikkeamien ja toimittajahäiriöiden aikana.

Viidenneksi alihankkijoiden läpinäkymättömyys. Organisaatio tuntee pääpalveluntarjoajan mutta ei pysty selittämään, mitkä alikäsittelijät tai tekniset palveluntarjoajat tukevat palvelua.

Kuudenneksi muutosten herätteiden puute. Palveluntarjoaja lisää uuden alikäsittelijän, vaihtaa pilvipalvelun sijaintialuetta, migroi arkkitehtuuria tai muuttaa tukipääsyä, mutta kukaan ei päivitä rekisteriä tai arvioi riskiä uudelleen.

Seitsemänneksi näytön aikataulun puute. Toimittajakatselmoinnille, sopimuskatselmoinnille, omaisuuden validoinnille, pilvirekisterin täsmäytykselle tai johdon raportoinnille ei ole määriteltyä tiheyttä.

Nämä ovat ratkaistavissa olevia asioita, mutta vain jos rekisterillä on omistajat ja työnkulut.

Käytännön 30 päivän parannussuunnitelma

Aloita soveltamisalasta. Tunnista kaikki liiketoimintatoiminnot, jotka voivat olla DORA:n mukaan kriittisiä tai tärkeitä. Listaa kunkin toiminnon osalta ICT-palvelut, joista se riippuu. Älä aloita hankintakuluista. Aloita operatiivisesta riippuvuudesta.

Täsmäytä keskeiset tietolähteet: toimittajarekisteri, sopimustietovarasto, omaisuusluettelo ja pilvipalvelurekisteri. Lisää tietosuojan käsittelijätallenteet ja poikkeamien hallinnan riippuvuudet tarvittaessa. Tavoitteena ei ole täydellisyys ensimmäisenä päivänä. Tavoitteena on yksi rekisterirunko, jossa tuntemattomat kohdat merkitään selvästi.

Luokittele toimittajat ja palvelut käyttämällä kriteerejä, kuten tuettu toiminto, tietojen arkaluonteisuus, operatiivinen korvattavuus, keskittymä, alihankinta, sijainnit, poikkeaman vaikutus, palautumisaika ja sääntelyrelevanssi.

Katselmoi jokaisen kriittisen tai tärkeän ICT-järjestelyn sopimukset. Tarkista, sisältääkö sopimus palvelukuvaukset, alihankintaa koskevat ehdot, sijainnit, tietosuojasitoumukset, pääsyn ja palautuksen, palvelutasot, poikkeamatilanteiden tuen, auditointioikeudet, viranomaisyhteistyön, irtisanomisen, koulutukseen osallistumisen ja irtautumistuen.

Kartoita ISO-näyttö jokaiselle kriittiselle järjestelylle. Linkitä omaisuustietueisiin, riskien arviointikirjauksiin, SoA-kontrolleihin, toimittajahuolellisuusarviointiin, seurantakatselmointeihin, jatkuvuussuunnitelmiin, poikkeamien toimintamalleihin ja irtautumisstrategian näyttöön.

Määritä aikataulu. Kriittiset palveluntarjoajat voivat edellyttää neljännesvuosittaista katselmointia, vuosittaista varmentamista, sopimuskatselmointia ennen uusimista ja välitöntä uudelleenarviointia olennaisen muutoksen yhteydessä. Ei-kriittiset palveluntarjoajat voidaan katselmoida vuosittain tai laukaisevien tapahtumien perusteella.

Käytä tätä tarkistuslistaa, jotta rekisteristä tulee toimiva prosessi:

• Nimeä DORA-rekisterin omistaja ja varahenkilö.
• Linkitä jokainen rekisteririvi sopimuksen tunnisteeseen ja toimittajaomistajaan.
• Linkitä jokainen kriittinen tai tärkeä ICT-palvelu liiketoimintatoimintoon ja omaisuustietueisiin.
• Lisää alihankkija- ja alikäsittelijäkentät, vaikka ne merkittäisiin aluksi tuntemattomiksi.
• Lisää sopimuslausekkeiden tila DORA-kriittisille ehdoille.
• Lisää ISO/IEC 27001:2022 -riskien ja SoA:n viittaukset.
• Lisää GDPR-rooli-, henkilötieto- ja sijaintikentät soveltuvin osin.
• Lisää katselmointitiheys ja viimeksi katselmoitu -metatiedot.
• Luo eskalointisäännöt puuttuville lausekkeille, tuntemattomille alihankkijoille ja korkealle keskittymäriskille.
• Raportoi rekisterin laatumittarit johdolle.

Tässä Clarysecin 30-vaiheinen toteutusmenetelmä, politiikkakokonaisuus ja Zenith Controls toimivat yhdessä. Zenith Blueprint antaa toteutuspolun Step 13:n riskien käsittelystä ja SoA-jäljitettävyydestä Step 22:n omaisuusluetteloon ja Step 23:n toimittajakontrolleihin. Politiikat määrittävät, kenen on ylläpidettävä rekistereitä, mitä sopimus- ja omaisuusnäyttöä on oltava olemassa ja miten vaatimustenmukaisuuden metatiedot kerätään. Zenith Controls tarjoaa ristikkäisen vaatimustenmukaisuuden kompassin saman näytön kartoittamiseen DORA:n, ISO/IEC 27001:2022:n, NIS2:n, GDPR:n, NIST:n ja COBIT 19:n auditointiodotuksiin.

Muuta rekisteri näytöksi ennen kuin valvoja pyytää sitä

Jos DORA-tietorekisterisi on edelleen laskentataulukko, joka on irti sopimuksista, omaisuuseristä, toimittajista, alihankkijoista ja ISO 27001 -näytöstä, vuosi 2026 on oikea aika korjata se.

Aloita käyttämällä Zenith Blueprint Zenith Blueprint -materiaalia riskien käsittelyn, omaisuusluettelon ja toimittajahallinnan yhdistämiseen. Käytä Zenith Controls Zenith Controls -materiaalia ISO/IEC 27001:2022:n liitteen A kontrollien A.5.9, A.5.19 ja A.5.20 kartoittamiseen ristikkäiseksi vaatimustenmukaisuusnäytöksi. Vie vaatimukset sen jälkeen käytäntöön Clarysecin toimittaja-, omaisuus-, pilvi-, lakisääteisten vaatimusten noudattamisen ja auditoinnin seurantapolitiikkojen kautta, mukaan lukien Third-Party and Supplier Security Policy - SME, Supplier Dependency Risk Management Policy, Third party and supplier security policy, Asset Management Policy - SME, Asset Management Policy, Cloud Usage Policy - SME, Legal and Regulatory Compliance Policy ja Audit and Compliance Monitoring Policy - SME.

Paras aika korjata rekisterin laatu on ennen viranomaispyyntöä, sisäistä tarkastusta, toimittajakatkosta tai sopimuksen uusimista. Toiseksi paras aika on nyt. Lataa asiaankuuluvat Clarysec-politiikat, kartoita nykyinen rekisterisi yllä olevaan näyttömalliin ja varaa DORA-rekisterin arviointi, jotta hajanaisesta toimittajadatasta saadaan valvontakelpoista näyttöä.