RoPA ja tietovirtojen kartoitus GDPR:n, NIS2:n ja DORA:n tueksi

On tiistaiaamu kello 09.10, ja tietoturvajohtaja, tietosuojavastaava, hankintavastaava ja operatiivinen johtaja katsovat samaa videopuhelua, mutta eivät samaa todentavaa aineistoa.

Tietosuojavastaavalla on käsittelytoimien seloste (RoPA), jossa luetellaan asiakkaiden käyttöönotto, työntekijöiden palkanlaskenta, tukipyynnöt ja markkinointianalytiikka. Tietoturvajohtajalla on pilviomaisuusluettelo. Hankinnalla on toimittajasopimukset. Operatiivisella toiminnolla on liiketoiminnan jatkuvuuden taulukko. Taloushallinnolla on DORA Register of Information. Kukaan ei pysty vastaamaan valvojan perustavanlaatuisimpaan kokonaiskysymykseen:

Jos tämä maksupalvelun käyttöönottopalvelu vikaantuu, mihin järjestelmiin, toimittajiin, tietoryhmiin, alikäsittelijöihin, rajat ylittäviin siirtoihin ja kriittisiin liiketoimintatoimintoihin se vaikuttaa?

Tämä kysymys on vuoden 2026 todellinen vaatimustenmukaisuustesti.

GDPR edellyttää edelleen osoitusvelvollisuuden mukaista 30 artiklan kirjanpitoa. NIS2 on tehnyt kyberturvallisuudesta johdon osoitusvelvollisuuskysymyksen keskeisille ja tärkeille toimijoille. DORA edellyttää, että finanssialan toimijat pystyvät esittämään näyttöä ICT-riippuvuuksista, kriittisistä tai tärkeistä toiminnoista, ICT-kolmansien osapuolten järjestelyistä, poikkeamien luokittelusta ja häiriönsietokyvyn testauksesta. ISO/IEC 27001:2022 tarjoaa hallintajärjestelmärakenteen, joka voi pitää kokonaisuuden koossa, mutta vain jos RoPA:aa ja tietovirtojen kartoitusta käsitellään elävänä hallinnointinäyttönä eikä tietosuojatiimin taulukoina.

Clarysecissä näemme saman mallin nopeasti kasvavissa SaaS-, fintech-, pilvi-, MSP- ja B2B-teknologiayrityksissä. Dokumentaatiota on riittävästi kyselylomakkeeseen vastaamiseen, mutta yhdistettyä todentavaa aineistoa ei ole riittävästi valvontatarkastuksen, kyberpoikkeaman, toimittajahäiriön tai sisäisen tarkastuksen kestämiseen. Ongelma on harvoin tiedon puute. Ongelma on yhteyksien puute.

Ratkaisu on tehdä RoPA:sta ja tietovirtojen kartoituksesta yhteinen näyttökerros tietosuojalle, kyberhäiriönsietokyvylle, toimittajahallinnalle, pilvipalvelujen hallinnalle ja liiketoiminnan jatkuvuudelle.

Miksi RoPA:sta ja tietovirtojen kartoituksesta tuli vuoden 2026 hallinnointikysymys

RoPA:aa pidettiin aiemmin tietosuojadokumenttina. Tietovirtojen karttoja laadittiin usein DPIA:n, pilvimigraation tai tietoturva-arkkitehtuurin katselmoinnin yhteydessä, minkä jälkeen ne jätettiin vanhenemaan. Tämä toimintatapa ei enää riitä.

GDPR soveltuu laajasti henkilötietojen käsittelyyn EU:ssa sijaitsevan toimipaikan yhteydessä sekä moniin EU:n ulkopuolisiin rekisterinpitäjiin tai henkilötietojen käsittelijöihin, jotka tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään. Henkilötiedot tarkoittavat tunnistettuun tai tunnistettavissa olevaan henkilöön liittyviä tietoja. Käsittely kattaa keräämisen, säilyttämisen, käytön, luovuttamisen, rajoittamisen, poistamisen ja hävittämisen. Rekisterinpitäjä määrittää käsittelyn tarkoitukset ja keinot, kun taas henkilötietojen käsittelijä toimii rekisterinpitäjän lukuun.

RoPA ei siis ole pelkkä tietokantaluettelo. Se on kirjanpito liiketoiminnallisista tarkoituksista, tietoryhmistä, rooleista, vastaanottajista, säilytysajoista, suojatoimista ja kansainvälisistä riippuvuuksista.

NIS2 lisää näkökulmaksi palvelujen häiriönsietokyvyn. Se tuo soveltamisalaan monia keskisuuria ja suurempia organisaatioita korkean kriittisyyden ja muilla kriittisillä toimialoilla, kuten digitaalisen infrastruktuurin, pilvipalveluntarjoajat, datakeskuspalveluntarjoajat, sisällönjakeluverkot, luottamuspalveluntarjoajat, yleiset sähköisen viestinnän tarjoajat, hallinnoidut palveluntarjoajat ja hallinnoidut tietoturvapalveluntarjoajat. Liite I sisältää myös pankkitoiminnan ja rahoitusmarkkinoiden infrastruktuurit. Osa toimijoista voi kuulua soveltamisalaan koosta riippumatta, mukaan lukien tietyt DNS-, TLD-, luottamuspalvelu- ja yleisen viestinnän tarjoajat sekä toimijat, joiden häiriö voisi vaikuttaa merkittävästi yleiseen turvallisuuteen, kansanterveyteen, järjestelmäriskiin tai kriittisiin yhteiskunnallisiin ja taloudellisiin toimintoihin.

NIS2:n 21 artikla edellyttää oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä toiminnassa tai palvelujen tuottamisessa käytettäville verkko- ja tietojärjestelmille. Vähimmäisalueisiin kuuluvat riskianalyysi, tietoturvapolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, turvallinen kehittäminen, vaikuttavuuden arviointi, kyberhygienia, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta ja todennus.

NIS2-toimijalle RoPA ilman näkymää palveluriippuvuuksiin on puutteellinen. Merkittävä poikkeama on ymmärrettävä palveluvaikutuksen, operatiivisen häiriön, vaikutuksen kohteena olevien vastaanottajien, toimittajien ja rajat ylittävien vaikutusten kautta.

DORA terävöittää saman vaatimuksen finanssialan toimijoille. Sitä sovelletaan 17. tammikuuta 2025 alkaen, ja se asettaa yhdenmukaiset vaatimukset ICT-riskien hallinnalle, merkittävien ICT:hen liittyvien poikkeamien raportoinnille, digitaalisen operatiivisen häiriönsietokyvyn testaukselle, kyberuhkia ja haavoittuvuuksia koskevien tietojen jakamiselle, ICT-kolmansien osapuolten riskille sekä sopimusjärjestelyille ICT-kolmansien osapuolten palveluntarjoajien kanssa. DORA määrittelee ICT-palvelut laajasti digitaalisiksi ja datapalveluiksi, joita tarjotaan ICT-järjestelmien kautta jatkuvasti. Se määrittelee kriittisen tai tärkeän toiminnon toiminnoksi, jonka häiriö heikentäisi olennaisesti taloudellista tulosta, palvelun jatkuvuutta tai vaatimustenmukaisuusvelvoitteita.

Finanssialan toimijoille, jotka on myös tunnistettu NIS2:n kansallisen täytäntöönpanon perusteella, DORA käsitellään alakohtaisena unionin säädöksenä vastaaville ICT-riskiä, poikkeamien raportointia, testausta, tietojen jakamista ja kolmannen osapuolen riskiä koskeville vaatimuksille. Käytännössä fintech-yritys ei voi rakentaa yhtä näyttökokonaisuutta tietosuojaa, toista DORA:a ja kolmatta NIS2:ta varten. Se tarvitsee yhden riippuvuustietoisen tiedonhallinnan kerroksen.

Tämä kerros on RoPA yhdistettynä tietovirtojen kartoitukseen.

ISO/IEC 27001:2022 on selkäranka

ISO/IEC 27001:2022 on rakennettu tällaista integrointia varten. Se perustaa skaalautuvan tietoturvallisuuden hallintajärjestelmän (ISMS), jonka tarkoituksena on säilyttää luottamuksellisuus, eheys ja saatavuus riskienhallinnan avulla. Standardi on tarkoitettu integroitavaksi organisaation prosesseihin ja skaalattavaksi organisaation tarpeiden, koon ja rakenteen mukaan.

Lähtökohta ei ole piirrostyökalu. Lähtökohta on soveltamisala.

ISO/IEC 27001:2022:n kohdat 4.1–4.4 edellyttävät, että organisaatio määrittää toimintaympäristönsä, sidosryhmät, ISMS:n soveltamisalan ja vuorovaikutuksessa olevat prosessit. Soveltamisalan on otettava huomioon lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset velvoitteet sekä rajapinnat ja riippuvuudet sisäisten toimintojen ja muiden organisaatioiden suorittamien toimintojen välillä. RoPA:n ja tietovirtojen kartoituksen kannalta tämä tarkoittaa, että ISMS:n soveltamisalan tulee nimenomaisesti kattaa ulkoistetut pilvialustat, maksunkäsittelijät, identiteetintarjoajat, tukityökalut, hallinnoidut tietoturvapalveluntarjoajat ja liiketoimintakriittiset SaaS-integraatiot.

Kohdat 5.1–5.3 tekevät johdosta vastuullisen politiikasta, resursseista, roolien osoittamisesta ja raportoinnista. Tämä vastaa NIS2:n 20 artiklan suuntaa: johdon on hyväksyttävä kyberturvallisuusriskien hallintatoimenpiteet, valvottava toteutusta ja osallistuttava koulutukseen. Se on yhdenmukainen myös DORA:n 5 artiklan kanssa, jossa johtavalle elimelle annetaan lopullinen vastuu ICT-riskistä sekä politiikkojen, häiriönsietostrategian, jatkuvuussuunnitelmien, auditointisuunnitelmien, ICT-kolmansien osapuolten palvelujen ja merkittävien poikkeamien raportointikanavien valvonnasta.

Kohdat 6.1.1–6.1.3 muodostavat suunnittelumoottorin: tunnistetaan luottamuksellisuuteen, eheyteen ja saatavuuteen kohdistuvat riskit, nimetään riskinomistajat, analysoidaan seuraukset ja todennäköisyys, valitaan riskinkäsittelyvaihtoehdot, verrataan kontrolleja liitteeseen A, laaditaan soveltuvuuslausunto ja hankitaan riskinomistajan hyväksyntä.

Tässä RoPA muuttuu operatiiviseksi. Jokainen käsittelytoimi ja tietovirta tulee yhdistää riskeihin, kontrolleihin, toimittajiin, omaisuuseriin ja kriittisiin palveluihin. Muussa tapauksessa se jää tietosuojaluetteloksi, joka ei tue tietoturvapoikkeamiin reagointia, häiriönsietokyvyn testausta tai toimittajariskipäätöksiä.

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap tekee tästä käytännöllistä riskienhallintavaiheen vaiheessa 9, Omaisuuserien, uhkien ja haavoittuvuuksien tunnistaminen:

Kirjaa jokaisesta omaisuuserästä keskeiset tiedot: nimi/kuvaus, omistaja, sijainti ja luokittelu (arkaluonteisuus). Esimerkiksi omaisuuserä voisi olla “Asiakastietokanta – IT-osaston omistama – isännöity AWS:ssä – sisältää henkilötietoja ja taloudellisia tietoja (korkea arkaluonteisuus).”

Sama vaihe 9 lisää keskeisen vaatimustenmukaisuusnäkökulman: henkilötietoja sisältävät omaisuuserät tulee merkitä GDPR-relevanteiksi, ja kriittisten palvelujen omaisuuserät tulee merkitä mahdollisen NIS2-soveltuvuuden näkökulmasta, jos organisaatio toimii säännellyllä toimialalla. Tämä on silta RoPA:n, omaisuusluettelon ja kriittisten palveluriippuvuuksien kartoituksen välillä.

Mitä auditointivalmiin RoPA:n tulee sisältää

Vahvan RoPA:n ei tarvitse olla monimutkainen, mutta sen on oltava yhdistetty.

GDPR:n 5 artikla edellyttää, että henkilötietoja käsitellään lainmukaisesti, kohtuullisesti ja läpinäkyvästi, kerätään määriteltyihin ja oikeutettuihin tarkoituksiin, rajoitetaan tarpeelliseen, pidetään täsmällisinä, säilytetään vain tarvittavan ajan ja suojataan asianmukaisilla teknisillä ja organisatorisilla toimenpiteillä. 5(2) artikla edellyttää, että rekisterinpitäjä vastaa vaatimusten noudattamisesta ja pystyy osoittamaan sen.

6 artikla edellyttää oikeusperustetta, kuten suostumusta, sopimuksen täytäntöönpanon välttämättömyyttä, lakisääteistä velvoitetta, elintärkeitä etuja, yleistä tehtävää tai oikeutettuja etuja. Jos käsittely tapahtuu uutta tarkoitusta varten, yhteensopivuus on arvioitava huomioimalla alkuperäinen ja uusi tarkoitus, keräämisen asiayhteys, arkaluonteisuus, seuraukset henkilöille ja suojatoimet, kuten salaus tai pseudonymisointi. 9 artikla lisää tiukemmat säännöt erityisiin henkilötietoryhmiin, kuten terveystietoihin, yksilölliseen tunnistamiseen käytettäviin biometrisiin tietoihin ja muihin arkaluonteisiin ryhmiin.

Clarysecin pk-yritysten politiikkakokonaisuus muuttaa tämän operatiiviseksi vaatimukseksi. Data Protection and Privacy Policy - SME toteaa:

Tietosuojakoordinaattorin on ylläpidettävä rekisteriä kaikista henkilötietojen käsittelytoimista, mukaan lukien tietoryhmät, tarkoitus, oikeusperuste ja säilytysajat.

Tämä on peräisin Hallinnointivaatimukset-osiosta, kohdasta 5.2.1. Suuremmille organisaatioille Clarysecin Data Protection and Privacy Policy osoittaa vastuun suoraan:

Ylläpitää käsittelytoimien selostetta (RoPA) GDPR:n 30 artiklan mukaisesti.

Tämä sanamuoto tulee Roolit ja vastuut -osiosta, kohdasta 4.2.2. Käytännön viesti on yksinkertainen: RoPA:n omistajuus on osoitettava. Se ei voi olla orpo vaatimustenmukaisuustaulukko.

Vuoteen 2026 valmis RoPA sisältää seuraavat kentät.

Viimeiset rivit siirtävät RoPA:n tietosuojadokumentaatiosta kyberhäiriönsietokyvyn näytöksi. Ilman järjestelmiä, toimittajia, sijainteja, kriittisyyttä ja kontrolleja RoPA voi täyttää kapean 30 artiklan tarkistuslistan, mutta epäonnistua heti, kun poikkeama, palvelukatkos tai valvontatarkastelu edellyttää vaikutusanalyysiä.

Tietovirtojen kartoitus yhdistää tietosuojan, pilven ja kriittiset palvelut

Jos RoPA vastaa kysymykseen “mitä käsittelyä on ja miksi”, tietovirtojen kartta vastaa kysymykseen “minne tiedot liikkuvat, kuka niihin koskee, mikä niitä suojaa ja mikä rikkoutuu, jos virta pysähtyy.”

Clarysecin Data Masking and Pseudonymization Policy - SME tekee vaatimuksesta yksiselitteisen:

Tietovirtojen kartta on laadittava.

Tämä tulee Hallinnointivaatimukset-osiosta, kohdasta 5.1.1.1. Yritysversio Data Masking and Pseudonymization Policy laajentaa odotusta kohdassa 5.2.1:

Ylläpidä ajantasaista luetteloa järjestelmistä ja tietovirroista, jotka sisältävät arkaluonteisia tietoja.

Kohta 5.2.2 lisää:

Kartoita, missä ja miten tietoja muunnetaan, jaetaan tai käytetään eri ympäristöissä.

Auditoijat ja valvontaviranomaiset eivät etsi taiteellisia kaavioita. He haluavat ymmärtää muunnokset, käyttöpolut, jakamisen, ympäristöt ja suojatoimet.

Zenith Blueprintin Controls in Action -vaiheen vaiheessa 22, Organizational controls 5.1 to 5.18, tiedonsiirtoa koskeva ohjeistus selittää, että organisaatioiden on määriteltävä sallitut siirtomenetelmät, sovitettava ne luokitteluun ja varmistettava, että osapuolet ymmärtävät roolinsa ja velvoitteensa. Esimerkkeinä annetaan salattu sähköposti, turvalliset portaalit, SFTP, ohjelmointirajapinnat ja fyysinen toimitus salauksella. Siinä todetaan myös, että rajojen yli siirrettävien henkilötietojen on täytettävä tietosuoja- ja lakisääteiset velvoitteet, ei pelkästään sisäisiä mieltymyksiä.

Sama vaihe yhdistää tiedonsiirron luokitteluun ja merkintöihin, tietovuotojen estämiseen, toimittajasuhteisiin ja kryptografiaan. Näin syntyy käytännön malli tietovirtojen kartoitukseen:

1. Tunnista lähdejärjestelmä, kuten CRM, maksualusta, HRIS tai tukipalvelu.
2. Tunnista tietoryhmä, mukaan lukien henkilötiedot, taloudelliset tiedot, työntekijätiedot, erityisiin henkilötietoryhmiin kuuluvat tiedot tai tunnistetiedot.
3. Tunnista siirtomenetelmä, kuten API, SFTP, sähköposti, turvallinen portaali, manuaalinen vienti tai varmuuskopioiden replikointi.
4. Tunnista kohde, mukaan lukien sisäinen järjestelmä, pilvipalvelu, toimittaja, alikäsittelijä, tietovarasto tai arkisto.
5. Tunnista suojaus, kuten salaus, pseudonymisointi, pääsynhallinta, lokitus, DLP tai sopimusperusteinen rajoitus.
6. Tunnista riippuvuus, mukaan lukien tukeeko tietovirta kriittistä liiketoimintatoimintoa, kriittistä tai tärkeää toimintoa, keskeistä palvelua tai poikkeaman raportointivelvoitetta.

Kolme ISO/IEC 27001:2022 liitteen A hallintakeinoa ovat tässä erityisen tärkeitä. ISO/IEC 27002:2022 antaa niiden toteutusohjeet:

Clarysecin Zenith Controls: The Cross-Compliance Guide tunnistaa 5.9:n, 5.14:n ja 5.34:n tämän hallinnointikerroksen aiheeseen liittyviksi kontrolleiksi. Käsittele niitä ankkurikontrolleina ja yhdistä ne toimittaja-, pilvi-, poikkeama-, jatkuvuus-, lokitus-, pääsynhallinta- ja kryptografiakontrolleihin soveltuvuuslausunnon kautta.

Miksi NIS2 ja DORA tarvitsevat enemmän kuin tietosuojarekisterin

Yleinen virhe on rakentaa RoPA, joka on GDPR:n näkökulmasta teknisesti oikein mutta NIS2:n tai DORA:n kannalta hyödytön. Ero on palvelun kriittisyydessä.

NIS2:n 23 artikla edellyttää, että keskeiset ja tärkeät toimijat ilmoittavat merkittävistä poikkeamista ilman aiheetonta viivytystä. Raportointimalli sisältää varhaisvaroituksen 24 tunnin kuluessa, poikkeamailmoituksen 72 tunnin kuluessa ja loppuraportin yhden kuukauden kuluessa. Merkittäviä poikkeamia arvioidaan vakavan operatiivisen häiriön, taloudellisen tappion tai muille luonnollisille tai oikeushenkilöille aiheutuneen aineellisen tai aineettoman vahingon perusteella. Tämä arviointi edellyttää tietoa siitä, mihin palveluihin, vastaanottajiin, maihin, järjestelmiin ja toimittajiin poikkeama vaikuttaa.

DORA:n 17 artikla edellyttää, että finanssialan toimijat määrittävät ja toteuttavat ICT:hen liittyvien poikkeamien hallintaprosessin, joka havaitsee, hallitsee ja ilmoittaa poikkeamista, kirjaa poikkeamat ja merkittävät kyberuhkat, tunnistaa juurisyyt, asettaa varhaisvaroitusindikaattorit, luokittelee poikkeamat vakavuuden ja vaikutuksen kohteena olevien palvelujen kriittisyyden perusteella, määrittää roolit sekä luo viestintä- ja eskalointimenettelyt. 18 artikla edellyttää luokittelua vaikutuksen kohteena olevien asiakkaiden tai vastapuolten ja tapahtumien, keston ja käyttökatkon, maantieteellisen laajuuden, saatavuuteen, aitouteen, eheyteen tai luottamuksellisuuteen vaikuttavan tietohäviön, vaikutuksen kohteena olevien palvelujen kriittisyyden sekä taloudellisen vaikutuksen perusteella.

Poikkeamaa ei voi luokitella nopeasti, jos tietovirtaa ja riippuvuusketjua ei tunneta.

Clarysecin Business Continuity Policy and Disaster Recovery Policy - SME osoittaa organisaatioiden tarvitseman näyttökentän:

priorisoidut palvelut ja järjestelmät (kriittiset liiketoimintatoiminnot)

Tämä tulee Hallinnointivaatimukset-osiosta, kohdasta 5.2.1.2. Yritystason Business Continuity Policy and Disaster Recovery Policy lisää riippuvuusulottuvuuden kohdassa 5.2.4:

Kriittiset riippuvuudet (järjestelmät, toimittajat, henkilöstö)

DORA-säännellyissä organisaatioissa tämän on oltava yhdenmukainen kriittisten tai tärkeiden toimintojen, ICT-palvelujen, sopimusjärjestelyjen ja exit-strategioiden kanssa. DORA:n 28 artikla edellyttää, että ICT-kolmansien osapuolten riskiä hallitaan osana ICT-riskikehystä. Se velvoittaa pitämään rekisteriä ICT-palvelujen sopimusjärjestelyistä, edellyttää ennen sopimusta tehtävää huolellisuusarviointia sekä kriittisyyden, keskittymäriskin, soveltuvuuden ja eturistiriitojen arviointia, ja vaatii exit-strategioita ICT-palveluille, jotka tukevat kriittisiä tai tärkeitä toimintoja.

DORA:n 30 artikla määrittää ICT-sopimusten vähimmäisehdot, kuten palvelukuvaukset, alihankinnan ehdot, tietojen käsittely- ja säilytyspaikat, tietosuojan, pääsyn, tietojen palautuksen ja takaisinluovutuksen, palvelutasot, poikkeama-avun, yhteistyön viranomaisten kanssa, irtisanomisoikeudet, auditointioikeudet sekä siirtymä- tai exit-järjestelyt.

RoPA, joka ei tunnista toimittajia, sijainteja, siirtomenetelmiä, kriittisyyttä ja exit-riippuvuuksia, ei tue DORA-näyttöä.

Toimittajien, pilven ja alikäsittelijöiden kartoituksessa näyttö usein pettää

Todellisissa auditoinneissa RoPA:n puutteet näkyvät usein toimittajapuutteina. Käsittelytoimessa lukee “asiakastuki”. Tietovirtojen kartassa lukee “tukialusta”. Kukaan ei kuitenkaan pysty tunnistamaan hosting-aluetta, AI-transkriptiolisäosaa, analytiikka-alikäsittelijää, tukipyyntöjen liitteiden säilytystä, ylläpitäjäpääsyn mallia tai exit-menettelyä.

Clarysecin pk-yritysten toimittajapolitiikka luo operatiivisen vähimmäisnäytön. Third-Party and Supplier Security Policy - SME toteaa:

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

Tämä tulee Hallinnointivaatimukset-osiosta, kohdasta 5.4. Pilvipalvelupolitiikka lisää erillisen luettelointivaatimuksen. Cloud Usage Policy - SME toteaa:

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

Tämä tulee Hallinnointivaatimukset-osiosta, kohdasta 5.3. Yritystason riippuvuusriskin osalta Clarysecin Supplier Dependency Risk Management Policy on täsmällisempi:

Toimittajariippuvuusrekisteri: toimittajahallintatoiminnon on ylläpidettävä ajantasaista rekisteriä kaikista kriittisistä toimittajista. Rekisteriin on sisällytettävä muun muassa tarjottavat palvelut/tuotteet; onko toimittaja ainoa lähde; käytettävissä olevat vaihtoehtoiset toimittajat tai korvattavuus; voimassa olevat sopimusehdot; sekä arvio vaikutuksesta, jos toimittaja vikaantuisi tai vaarantuisi. Rekisterissä on tunnistettava selkeästi suuren riippuvuuden toimittajat (esim. ne, joille ei ole nopeasti käytettävissä olevaa vaihtoehtoa).

Tämä vaatimus, joka tulee Toteutusvaatimukset-osion kohdasta 6.1, yhdistää täsmälleen RoPA:n NIS2:n toimitusketjun tietoturvaan ja DORA:n ICT-kolmansien osapuolten riskiin.

Zenith Blueprintin Controls in Action -vaiheen vaihe 23, Organizational controls 5.19 to 5.37, suosittelee koko toimittajaluettelon kokoamista, toimittajien luokittelua järjestelmiin, tietoihin tai operatiiviseen valvontaan kohdistuvan pääsyn perusteella, tietoturvaodotusten sisällyttämistä sopimuksiin, alihankkijoiden katselmointia, toimittajamuutosten herätteiden määrittämistä sekä pilvipalvelujen arviointiprosessin rakentamista siten, että se kattaa tietojen sijainnin, pääsymallin, lokituksen ja salauksen.

Tämän ansiosta tietoturvajohtaja voi poikkeamatilanteessa vastata: “Mikä kriittinen palvelu käyttää tätä toimittajaa, mitä tietoja altistui, mille asiakkaille on ilmoitettava, mille valvojalle raportti voi olla tarpeen ja mikä vaihtoehtoinen toimittaja tai exit-polku on olemassa?”

Käytännön esimerkki: asiakkaan käyttöönotto fintech-yrityksessä

Tarkastellaan fintech-yritystä, joka tarjoaa digitaalisen lompakon käyttöönottoa. Asiakkaat lataavat henkilöllisyysasiakirjoja, toimittaja suorittaa biometriset liveness-tarkistukset, tulokset tallennetaan pilvitietokantaan, ja asiakastuki voi nähdä varmennuksen tilan tikettijärjestelmässä.

Käyttöönottopalvelu voi olla DORA:n mukainen kriittinen tai tärkeä toiminto, koska häiriö vaikuttaa olennaisesti palvelun jatkuvuuteen ja sääntelyvelvoitteisiin. Jos yritys toimii NIS2-toimialalla tai tarjoaa relevantteja ICT-palveluja, se voi myös olla osa kriittisen palvelun näyttöä.

Hyödyllinen kartta alkaa yhdestä yhdistetystä tietueesta.

Lisää seuraavaksi ISO/IEC 27001:2022 -riskien käsittelyn jäljitettävyys.

Zenith Blueprintin riskienhallintavaiheen vaiheessa 13, Riskienkäsittelysuunnittelu ja soveltuvuuslausunto, Clarysec kuvaa SoA:n yhdistäväksi asiakirjaksi, joka liittää riskien arvioinnin ja käsittelyn todellisiin kontrolleihin. Se suosittelee kontrollien kartoittamista riskeihin ja sellaisten säädösten kuin GDPR, NIS2 tai DORA ristiviittaamista riskirekisterissä tai SoA-muistiinpanoissa, kun se on relevanttia.

Käyttöönottoesimerkissä riskiskenaario voisi olla: “Identiteetin varmennuksen palveluntarjoajan käyttökatko tai vaarantuminen keskeyttää käyttöönoton ja altistaa biometriset henkilöllisyystiedot.” Käsittelykontrolleja voivat olla toimittajahuolellisuusarviointi, sopimusperusteinen poikkeamailmoitus, salaus, pääsynhallinta, lokitus, varmuuskopiointi ja palautus, tietojen minimointi, pseudonymisointi, seuranta, exit-suunnittelu ja tietoturvapoikkeamiin reagoinnin pelikirjat.

SoA-muistiinpano voi todeta, että kontrollikokonaisuus tukee GDPR:n osoitusvelvollisuutta, NIS2:n 21 artiklan toimitusketjua ja valmiutta poikkeamatilanteisiin sekä DORA:n ICT-kolmansien osapuolten riskiä ja kriittisen toiminnon häiriönsietokykyä.

Tätä auditoijat haluavat: jäljitettävyyttä.

Yhteinen vaatimustenmukaisuuskartoitus: yksi näyttökerros, useita kysymyksiä

RoPA ja tietovirtojen kartoitus eivät ole erillisiä vaatimustenmukaisuussiiloja. Ne tukevat yhteistä kysymysjoukkoa GDPR:n, NIS2:n, DORA:n, ISO/IEC 27001:2022:n, NIST CSF 2.0:n ja COBIT 2019:n välillä.

NIST CSF 2.0 toimii hyvin jäsentävänä kerroksena. Sen CSF Profiles tukevat nykytilan ja tavoitetilan analyysiä käyttäen syötteinä muun muassa politiikkoja, riskiprioriteetteja, liiketoimintavaikutusrekistereitä, vaatimuksia, standardeja, käytäntöjä, työkaluja ja työrooleja. Sen GOVERN-toiminto sisältää lakisääteiset, sääntelyyn perustuvat, sopimusperusteiset, tietosuojaan ja kansalaisvapauksiin liittyvät velvoitteet, riskitavoitteet, johdon vastuun, roolit, politiikan, valvonnan ja suorituskyvyn katselmoinnin. Sen toimitusketjutulokset edellyttävät, että toimittajat tunnetaan ja priorisoidaan kriittisyyden perusteella, sopimusperusteiset kyberturvallisuusvaatimukset integroidaan, huolellisuusarviointi tehdään ennen suhteiden aloittamista, toimittajariskit kirjataan ja niitä seurataan, ja toimittajat sisällytetään tietoturvapoikkeamiin reagoinnin ja palautumisen suunnitteluun.

Tämä vastaa selkeästi Clarysecin RoPA-toimintamallia. RoPA antaa tietosuojakontekstin. Omaisuusluettelo antaa teknisen kontekstin. Toimittaja- ja pilvirekisterit antavat kolmannen osapuolen kontekstin. BIA antaa kriittisyyskontekstin. SoA antaa kontrollikontekstin.

Yksi ISO/IEC 27001:2022 liitteen A hallintakeino voi myös tukea useita viitekehyksiä. Hallintakeino 5.14, Tietojen siirto, on hyvä esimerkki.

Tässä on Zenith Controls -oppaan arvo yhteisen vaatimustenmukaisuuden kompassina. Se auttaa organisaatioita selittämään, miksi yksi kontrollikäytäntö tukee useita sääntely- ja auditointiodotuksia.

Miten eri auditoijat testaavat samaa karttaa

Kypsä RoPA ja tietovirtojen kartta voi vastata useiden auditoijien tarpeisiin, mutta kukin lähestyy sitä eri tavalla.

ISO/IEC 27001:2022 -auditoija aloittaa soveltamisalasta, sidosryhmistä, riskeistä, dokumentoidusta tiedosta ja kontrollien valinnasta. Hän kysyy, onko lakisääteiset ja sopimusperusteiset vaatimukset tunnistettu, sisältyvätkö henkilötiedot ja kriittiset palvelut ISMS:n soveltamisalaan, onko omaisuuserillä omistajat ja luokittelut, huomioiko riskien arviointi luottamuksellisuuden, eheyden ja saatavuuden, ja perusteleeko SoA sovellettavat kontrollit.

GDPR-auditoija tai tietosuojaviranomainen aloittaa osoitusvelvollisuudesta. Hän testaa, vastaako RoPA todellista käsittelyä, onko tarkoitukset ja oikeusperusteet dokumentoitu, onko erityisiin henkilötietoryhmiin kuuluvat tiedot tunnistettu, sovelletaanko säilytysaikoja, ovatko vastaanottajat ja henkilötietojen käsittelijät täsmällisiä, ja onko siirroille ja turvallisuudelle asianmukaiset suojatoimet.

NIS2-painotteinen auditoija tarkastelee palveluvaikutusta. Hän kysyy, miten organisaatio määrittää kriittiset tai tärkeät palvelut, miten johto on hyväksynyt riskitoimenpiteet ja valvoo niitä, miten toimittajien haavoittuvuudet ja palveluntarjoajariskit huomioidaan, miten jatkuvuus ja poikkeamien käsittely on yhdistetty, ja pystyykö organisaatio tukemaan 24 tunnin, 72 tunnin ja loppuraportoinnin määräaikoja luotettavalla näytöllä.

DORA-auditoija tarkastelee ICT-riskien hallinnointia ja kriittisiä tai tärkeitä toimintoja. Hän testaa, onko johtava elin hyväksynyt ICT-riskikehyksen ja häiriönsietostrategian, onko ICT-kolmansien osapuolten järjestelyt rekisteröity, onko kriittisyys ja keskittymäriski arvioitu, sisältävätkö sopimukset vaaditut ehdot, kattaako testaus kriittisiä tai tärkeitä toimintoja tukevat järjestelmät, ja luokitellaanko poikkeamat vaikutuksen kohteena olevien asiakkaiden, tapahtumien, käyttökatkon, maantieteen, tietohäviön, palvelun kriittisyyden ja taloudellisen vaikutuksen perusteella.

NIST CSF 2.0 -arvioija käyttää usein profiileja. Hän vertaa nykyisiä ja tavoiteltuja tuloksia GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- ja RECOVER-toiminnoissa. RoPA:sta ja tietovirtojen kartoista tulee syötteitä lakisääteisten velvoitteiden hallintaan, omaisuusluetteloihin, toimittajariskiin, tietosuojaan, seurantaan, poikkeamaviestintään ja palautumissuunnitteluun.

COBIT 2019- tai ISACA-tyyppinen auditoija keskittyy hallinnointiin, omistajuuteen ja prosessikyvykkyyteen. Hän testaa, onko tietovirroilla omistajat, ovatko päätösoikeudet selkeät, sovelletaanko riskinottohalukkuutta, seurataanko kontrolleja, eskaloidaanko poikkeukset ja onko näyttö riittävän luotettavaa johdon varmistusta varten.

Yleiset epäonnistumismallit

Yleisimmät RoPA:n ja tietovirtojen kartoituksen puutteet ovat ennakoitavissa.

Ensinnäkin RoPA luettelee käsittelytoimet mutta ei järjestelmiä. Tämä tekee mahdottomaksi yhdistää GDPR:n osoitusvelvollisuuden haavoittuvuuksien hallintaan, käyttöoikeuskatselmointiin, varmuuskopiointiin, lokitukseen tai tietoturvapoikkeamiin reagointiin.

Toiseksi tietovirtojen kartat pysähtyvät ensimmäiseen toimittajaan. Ne eivät näytä alikäsittelijöitä, pilvialueita, tukikäyttöä, analytiikkatyökaluja, seurantajärjestelmiä tai varmuuskopiointisijainteja.

Kolmanneksi liiketoiminnan jatkuvuussuunnitelmat tunnistavat järjestelmät mutta eivät henkilötietoja. Palvelukatkon aikana organisaatio ymmärtää palautusprioriteetin mutta ei tietosuojavaikutusta.

Neljänneksi toimittajarekisterit tallentavat sopimusomistajat mutta eivät kriittisyyttä, korvattavuutta, tietoryhmiä, poikkeamailmoitusvelvoitteita tai exit-vaihtoehtoja.

Viidenneksi SoA on kirjoitettu sertifiointiasiakirjaksi eikä kontrollisillaksi. Siinä todetaan, että kontrollit ovat sovellettavia, mutta ei selitetä, minkä GDPR-, NIS2- tai DORA-näyttöongelman ratkaisemista kontrolli tukee.

Lopuksi omistajuus on pirstaloitunut. Tietosuojavastaava omistaa RoPA:n, IT omistaa omaisuuserät, hankinta omistaa toimittajat, operatiivinen toiminto omistaa BIA:n, taloushallinto omistaa DORA-rekisterit, eikä kukaan omista integroitua riippuvuuskarttaa.

Clarysecin lähestymistapa korjaa tämän osoittamalla näyttöobjektit politiikan omistajille ja käyttämällä sen jälkeen Zenith Blueprint -vaiheita omaisuuserien, riskien, kontrollien ja SoA-jäljitettävyyden yhdistämiseen.

30 päivän toteutussuunnitelma

Kaikkea ei tarvitse ratkaista kerralla. Aloita palveluista, joilla on eniten merkitystä.

Viikko 1: Valitse kolme kriittistä tai korkean riskin käsittelytoimea. Hyviä ehdokkaita ovat asiakkaiden käyttöönotto, maksujen käsittely, henkilöstöhallinnon työntekijähallinto, tukipyyntöjen käsittely tai tietoturvavalvonta. Varmista jokaisen osalta, että RoPA-merkintä vastaa todellisia järjestelmiä, tietoryhmiä, tarkoituksia, oikeusperusteita ja säilytyssääntöjä.

Viikko 2: Laadi tietovirtojen kartat näille toimille. Tunnista lähde, kohde, siirtomenetelmä, ympäristö, toimittaja, alikäsittelijä, tietojen sijainti, pääsypolku, muunnos ja säilytyskohta. Hyödynnä Clarysecin Data Masking and Pseudonymization Policy -vaatimusta ylläpitää luetteloita järjestelmistä ja tietovirroista, jotka sisältävät arkaluonteisia tietoja.

Viikko 3: Yhdistä jokainen tietovirta omaisuuseriin, toimittajiin, pilvipalveluihin ja kriittisiin liiketoimintatoimintoihin. Käytä Zenith Blueprint Step 9:ää omaisuuserien omistajuuteen ja luokitteluun. Käytä toimittaja- ja pilvirekisteripolitiikan vaatimuksia kolmansien osapuolten näytön keräämiseen. Käytä liiketoiminnan jatkuvuuspolitiikkaa priorisoitujen palvelujen ja kriittisten riippuvuuksien tunnistamiseen.

Viikko 4: Lisää riskien ja kontrollien jäljitettävyys. Luo tai päivitä riskiskenaariot jokaiselle tietovirralle. Kartoita kontrollit SoA:ssa käyttäen Zenith Blueprint Step 13:a. Lisää tarvittaessa huomautukset GDPR:n 30 artiklan osoitusvelvollisuudesta, NIS2:n 21 artiklan riskitoimenpiteistä ja DORA:n ICT-riippuvuusnäytöstä.

Suorita sitten yksi pöytäharjoitus: “Toimittajan käyttökatko ja tietojen altistuminen kriittisessä palvelussa.” Testaa, tukeeko näyttö poikkeamien luokittelua, ilmoituspäätöksiä, asiakasviestintää, viranomaisviestintää ja palautumisen priorisointia.

30 päivän lopussa sinulla on toistettava malli organisaation muulle osalle.

Clarysecin tapa: muuta RoPA eläväksi häiriönsietokyvyn näytöksi

RoPA ja tietovirtojen kartoitus eivät enää ole pelkkää tietosuojahallintoa. Ne ovat yhdistävä kudos GDPR:n osoitusvelvollisuuden, NIS2:n kriittisten palvelujen hallinnoinnin ja DORA:n ICT-riippuvuusnäytön välillä.

Vuonna 2026 parhaiten suoriutuvat organisaatiot eivät ole niitä, joilla on eniten asiakirjoja. Ne ovat organisaatioita, jotka pystyvät jäljittämään liiketoimintapalvelun sen käsittelytoimiin, tietovirtoihin, järjestelmiin, toimittajiin, pilvialueisiin, sopimuksiin, kontrolleihin, riskeihin, poikkeamakynnyksiin ja palautussuunnitelmiin.

Clarysec auttaa tiimejä rakentamaan tämän jäljitettävyyden ilman tarpeetonta byrokratiaa. Politiikkakokonaisuutemme osoittaa omistajuuden ja näyttövaatimukset. Zenith Blueprint tarjoaa toteutuksen tiekartan, mukaan lukien omaisuuserien tunnistamisen, toimittaja- ja pilvikontrollien toteutuksen sekä SoA-jäljitettävyyden. Zenith Controls tarjoaa yhteisen vaatimustenmukaisuuden kompassin ISO/IEC 27001:2022 liitteen A kontrollien kartoittamiseksi tietosuoja-, häiriönsietokyky-, toimittaja-, pilvi- ja auditointiodotuksiin.

Seuraava askel on yksinkertainen: valitse yksi kriittinen palvelu, yksi RoPA-merkintä ja yksi toimittajan tukema tietovirta. Kartoita se päästä päähän. Jos et pysty selittämään tietoja, riippuvuutta, kontrollia ja poikkeaman vaikutusta yhdellä sivulla, näyttökerroksesi ei ole valmis vuoteen 2026.

Clarysec voi auttaa saattamaan sen valmiiksi. Tutustu Zenith Blueprint -ratkaisuun, vahvista hallinnointia Data Protection and Privacy Policy- ja Supplier Dependency Risk Management Policy -politiikoilla ja käytä Zenith Controls -opasta muuttaaksesi pirstaleisen vaatimustenmukaisuusnäytön yhdeksi auditointivalmiiksi toimintamalliksi.