GDPR Article 32:n TOMs-näyttö ISO 27001-, NIS2- ja DORA-kartoituksella
Sähköposti saapuu tietoturvajohtajan postilaatikkoon tutulla painolla: kyseessä on mahdollisuus, joka voi muuttaa koko vuosineljänneksen.
Merkittävä potentiaalinen yritysasiakas pyytää näyttöä ”GDPR Article 32:n teknisistä ja organisatorisista toimenpiteistä, kartoitettuna ISO 27001:2022:een, NIS2:een ja DORA:an soveltuvin osin.” Samaan aikaan lakiosasto on informoinut hallitusta NIS2:n johdon vastuusta ja DORA:n digitaalista operatiivista häiriönsietokykyä koskevista odotuksista. Hallituksen ohje kuulostaa yksinkertaiselta: osoittakaa vaatimustenmukaisuus, välttäkää päällekkäinen työ ja älkää tehkö tästä kolmea erillistä hanketta.
Organisaatiolla on kontrollit. MFA on käytössä. Varmuuskopiot ajetaan. Kehittäjät tekevät koodikatselmointeja. Tietosuojatiimi ylläpitää selosteita käsittelytoimista. Infrastruktuuritiimi skannaa haavoittuvuuksia. Toimittajia arvioidaan hankinnan yhteydessä. Mutta kun potentiaalinen asiakas pyytää näyttöä, vastaus hajoaa osiin.
Identiteetinhallintapalvelun raportti on yhdessä paikassa. Varmuuskopiointilokit ovat toisessa. Riskirekisteriä ei ole päivitetty viimeisimmän tuotejulkaisun jälkeen. Toimittajaturvallisuutta koskeva näyttö on hankinnan sähköposteissa. Tietoturvapoikkeamiin reagoinnin pöytäharjoitusten muistiinpanot ovat olemassa, mutta kukaan ei pysty osoittamaan, että opit on viety takaisin riskien käsittelyyn. Hallitus on hyväksynyt tietoturvabudjetin, mutta hyväksyntää ei ole kytketty ICT-riskiin tai dokumentoituun kontrollipäätökseen.
Tämä on GDPR Article 32:n teknisten ja organisatoristen toimenpiteiden, yleisesti TOMs-toimenpiteiden, todellinen ongelma. Useimmat organisaatiot eivät epäonnistu siksi, ettei niillä olisi kontrolleja. Ne epäonnistuvat siksi, etteivät ne pysty osoittamaan, että kontrollit ovat riskiperusteisia, hyväksyttyjä, toteutettuja, seurattuja ja parannettuja.
GDPR:n osoitusvelvollisuus tekee odotuksesta nimenomaisen. GDPR Article 5 edellyttää, että henkilötiedot suojataan asianmukaisella turvallisuudella luvatonta tai lainvastaista käsittelyä sekä vahingossa tapahtuvaa häviämistä, tuhoutumista tai vahingoittumista vastaan. Article 5(2) tekee rekisterinpitäjästä vastuullisen vaatimustenmukaisuuden osoittamisesta. Myös GDPR:n määritelmillä on merkitystä. Henkilötiedot ovat laaja käsite, käsittely kattaa lähes kaikki tietoihin kohdistuvat toimet, pseudonymisointi on tunnustettu suojatoimi, ja henkilötietojen tietoturvaloukkaus kattaa vahingossa tapahtuvan tai lainvastaisen tuhoutumisen, häviämisen, muuttamisen, luvattoman luovuttamisen tai luvattoman pääsyn.
Article 32:n näyttökokonaisuus ei siksi voi olla satunnaisten kuvakaappausten kansio. Sen on oltava elävä kontrollijärjestelmä.
Clarysecin lähestymistapa muuntaa GDPR Article 32:n TOMs-toimenpiteet jäljitettäväksi näyttöjärjestelmäksi, joka perustuu ISO/IEC 27001:2022 -standardiin ISO/IEC 27001:2022, jota vahvistaa ISO/IEC 27005:2022 -riskienhallinta ja joka viittaa NIS2- ja DORA-velvoitteisiin silloin, kun ne soveltuvat. Tavoitteena ei ole tuottaa dokumentaatiota dokumentaation vuoksi. Tavoitteena on varmistaa auditointivalmius ennen kuin asiakas, auditoija, viranomainen tai hallituksen jäsen esittää vaikean kysymyksen.
Miksi GDPR Article 32:n TOMs-toimenpiteet epäonnistuvat käytännössä
Article 32 ymmärretään usein virheellisesti tietoturvatyökalujen luetteloksi: salaus, varmuuskopiot, lokitus, pääsynhallinta ja tietoturvapoikkeamiin reagointi. Nämä toimenpiteet ovat tärkeitä, mutta ne ovat puolustettavissa vain silloin, kun ne ovat riskiin nähden asianmukaisia ja kytketty henkilötietojen elinkaareen.
SaaS-yritykselle, joka käsittelee asiakkaiden työntekijätietoja, ”käytämme salausta” ei riitä. Auditoija voi kysyä, mitä tietoja salaus suojaa, missä salaus on pakollinen, miten avaimia hallitaan, ovatko varmuuskopiot salattuja, peitetäänkö tuotantodata testauksessa, kuka voi ohittaa kontrollit ja miten poikkeukset hyväksytään.
Clarysecin yritystason tietosuoja- ja yksityisyydensuojapolitiikka tiivistää toimintaperiaatteen:
”Toteuta tekniset ja organisatoriset toimenpiteet (TOMs), jotka suojaavat henkilötietojen luottamuksellisuutta, eheyttä ja saatavuutta koko niiden elinkaaren ajan.”
Lähde: Tietosuoja- ja yksityisyydensuojapolitiikka, tavoitteet, politiikan kohta 3.3. Tietosuoja- ja yksityisyydensuojapolitiikka
Ilmaus ”koko niiden elinkaaren ajan” on kohta, jossa monet TOMs-ohjelmat heikkenevät. Henkilötiedot voivat olla suojattuja tuotannossa, mutta niitä voidaan kopioida analytiikkajärjestelmiin, lokeihin, tukivienteihin, testiympäristöihin, varmuuskopioihin, toimittaja-alustoihin ja työntekijöiden laitteille. Jokainen sijainti luo tietoturva- ja tietosuojariskin.
GDPR Article 6 edellyttää käsittelylle oikeusperustetta, kuten suostumusta, sopimusta, lakisääteistä velvoitetta, elintärkeitä etuja, yleistä etua koskevaa tehtävää tai oikeutettuja etuja. Kun tietoja käytetään uudelleen toiseen tarkoitukseen, yhteensopivuus ja suojatoimet, kuten salaus tai pseudonymisointi, on arvioitava. Korkeamman riskin tietojen osalta näyttövaatimus kasvaa. GDPR Article 9 asettaa tiukat rajat erityisiin henkilötietoryhmiin kuuluville tiedoille, kuten terveystiedoille, tunnistamiseen käytettäville biometrisille tiedoille ja muille arkaluonteisille tiedoille. Article 10 rajoittaa rikostuomioihin ja rikkomuksiin liittyvien tietojen käsittelyä.
Pk-yrityksille Clarysec ilmaisee riskien käsittelyn käytännönläheisesti:
”Kontrollit on toteutettava tunnistettujen riskien vähentämiseksi, mukaan lukien salaus, anonymisointi, turvallinen hävittäminen ja pääsyrajoitukset”
Lähde: Tietosuoja- ja yksityisyydensuojapolitiikka pk-yrityksille, riskien käsittely ja poikkeukset, politiikan kohta 7.2.1. Data Protection and Privacy Policy - SME
Tämä on vahva TOMs-perustaso. Jotta siitä tulee auditointivalmis, jokainen kontrolli on lisäksi kytkettävä riskiin, omistajaan, politiikkavaatimukseen, näyttökohteeseen ja katselmointirytmiin.
ISO 27001:2022 on Article 32 -näytön selkäranka
ISO 27001:2022 soveltuu hyvin GDPR Article 32:n näyttöön, koska se käsittelee tietoturvaa hallintajärjestelmänä eikä irrallisena kontrollien tarkistuslistana. Se edellyttää tietoturvallisuuden hallintajärjestelmää eli ISMS:ää, joka on suunniteltu säilyttämään luottamuksellisuus, eheys ja saatavuus riskienhallinnan avulla.
Ensimmäinen kriittinen toimenpide on soveltamisalan määrittäminen. ISO 27001:2022:n kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää sisäiset ja ulkoiset tekijät, tunnistaa sidosryhmät ja vaatimukset, määrittää, mitkä vaatimukset käsitellään ISMS:ssä, ja määrittelee ISMS:n soveltamisalan, mukaan lukien rajapinnat ja riippuvuudet ulkoisiin organisaatioihin. Article 32:n TOMs-toimenpiteiden osalta ISMS:n soveltamisalan tulee heijastaa henkilötietojen käsittelyä, asiakasvelvoitteita, käsittelijöitä, alikäsittelijöitä, pilvialustoja, etätyötä, tukitoimintoja ja tuoteympäristöjä.
Toinen toimenpide on johtajuus. Kohdat 5.1–5.3 edellyttävät ylimmän johdon sitoutumista, tietoturvapolitiikkaa, resursseja, rooleja ja vastuita sekä suorituskyvyn raportointia. Tällä on merkitystä, koska GDPR Article 32, NIS2 ja DORA nojaavat kaikki hallinnointiin. Kontrolli ilman omistajuutta, rahoitusta tai katselmointia on heikkoa näyttöä.
Clarysecin yritystason tietoturvapolitiikka tekee tämän selväksi:
”ISMS:n on sisällettävä määritellyt soveltamisalan rajat, riskienarviointimenetelmä, mitattavat tavoitteet ja dokumentoidut kontrollit, jotka on perusteltu soveltuvuuslausunnossa (SoA).”
Lähde: Tietoturvapolitiikka, politiikan toteutusvaatimukset, politiikan kohta 6.1.2. Tietoturvapolitiikka
Sama politiikka määrittää näyttöä koskevan odotuksen:
”Kaikkien toteutettujen kontrollien on oltava auditoitavissa, niitä on tuettava dokumentoiduilla menettelyillä ja niiden toiminnasta on säilytettävä näyttö.”
Lähde: Tietoturvapolitiikka, politiikan toteutusvaatimukset, politiikan kohta 6.6.1.
ISO 27001:2022:n kohdat 6.1.1–6.1.3 edellyttävät tämän jälkeen riskien arviointia, riskien käsittelyä, soveltuvuuslausuntoa, jäännösriskin hyväksyntää ja riskinomistajan osoitettua vastuuta. Kohta 6.2 edellyttää mitattavia tavoitteita. Kohdat 7.5, 9.1, 9.2, 9.3 ja 10.2 edellyttävät dokumentoitua tietoa, seurantaa, sisäistä tarkastusta, johdon katselmointia ja korjaavia toimenpiteitä.
GDPR Article 32:n kannalta tämä luo puolustettavan rakenteen.
| GDPR Article 32:n näyttökysymys | ISO 27001:2022:n näyttövastaus |
|---|---|
| Miten päätitte, mitkä TOMs-toimenpiteet ovat asianmukaisia? | Riskien arviointikriteerit, riskirekisteri, todennäköisyyden ja vaikutuksen pisteytys, riskienkäsittelysuunnitelma |
| Mitkä kontrollit soveltuvat ja miksi? | Soveltuvuuslausunto sekä sisällyttämis- ja poissulkemisperustelut |
| Kuka hyväksyi jäännösriskin? | Riskinomistajan hyväksyntä ja johdon hyväksyntä |
| Toimivatko kontrollit? | Lokit, tiketit, katselmointitallenteet, testitulokset, seurantaraportit |
| Katselmoidaanko kontrollit? | Sisäisen tarkastuksen raportit, johdon katselmointipöytäkirjat, korjaavien toimenpiteiden loki |
| Huomioidaanko henkilötietoihin liittyvät riskit? | Tietosuojariskimerkinnät, soveltamisalaan sisällytetyt tietosuojavaatimukset, DPIA tai vastaava arviointi soveltuvin osin |
ISO/IEC 27005:2022 vahvistaa tätä rakennetta. Se ohjaa organisaatioita tunnistamaan vaatimuksia ISO 27001:2022:n liitteestä A, sääntelystä, sopimuksista, toimialastandardeista, sisäisistä säännöistä ja olemassa olevista kontrolleista sekä syöttämään ne riskien arviointiin ja käsittelyyn. Se edellyttää myös riskikriteerejä ja hyväksymiskriteerejä, joissa huomioidaan oikeudelliset, sääntelyyn liittyvät, operatiiviset, toimittaja-, teknologia- ja inhimilliset tekijät, mukaan lukien tietosuoja.
Clarysecin riskienhallintapolitiikka on suoraan linjassa tämän kanssa:
”Muodollista riskienhallintaprosessia on ylläpidettävä ISO/IEC 27005:n ja ISO 31000:n mukaisesti kattaen riskien tunnistamisen, analyysin, arvioinnin, käsittelyn, seurannan ja viestinnän.”
Lähde: Riskienhallintapolitiikka, hallinnointivaatimukset, politiikan kohta 5.1. Riskienhallintapolitiikka
Pk-yrityksille sama vaatimus muuttuu yksinkertaiseksi ja toteutuskelpoiseksi:
”Jokaisen riskimerkinnän on sisällettävä: kuvaus, todennäköisyys, vaikutus, pisteet, omistaja ja riskienkäsittelysuunnitelma.”
Lähde: Riskienhallintapolitiikka pk-yrityksille, hallinnointivaatimukset, politiikan kohta 5.1.2. Risk Management Policy - SME
Tämä lause on nopea valmiustesti vaatimustenmukaisuuden osoittamiseen. Jos riskillä ei ole omistajaa tai käsittelysuunnitelmaa, riski ei ole vielä näyttövalmis.
Clarysec-silta: riski, SoA, kontrollit ja sääntely
Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint käsittelee vaatimustenmukaisuutta jäljitettävyystyönä. Riskienhallintavaiheessa Step 13 keskittyy riskienkäsittelyn suunnitteluun ja soveltuvuuslausuntoon. Se selittää, että organisaatioiden tulee kartoittaa kontrollit riskeihin, lisätä liite A:n kontrolliviittaukset riskienkäsittelymerkintöihin, ristiviitata ulkoiseen sääntelyyn ja hankkia johdon hyväksyntä.
Zenith Blueprint kuvaa SoA:n roolin suoraan:
”SoA on käytännössä siltadokumentti: se yhdistää riskien arvioinnin ja käsittelyn käytössä oleviin varsinaisiin kontrolleihin. Kun täytät sen, tarkistat samalla, puuttuuko jokin kontrolli.”
Lähde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, riskienhallintavaihe, Step 13: Risk Treatment Planning and Statement of Applicability (SoA). Zenith Blueprint
Zenith Blueprintin Step 14 lisää sääntelyyn kohdistuvan ristiviittauskerroksen. Se ohjaa organisaatioita dokumentoimaan, miten GDPR-, NIS2- ja DORA-vaatimukset katetaan politiikoilla ja kontrolleilla. GDPR:n osalta se korostaa henkilötietojen suojaa riskien arvioinneissa ja käsittelyissä, mukaan lukien salaus teknisenä toimenpiteenä ja loukkauksiin reagointi osana kontrolliympäristöä. NIS2:n osalta se nostaa esiin riskien arvioinnin, verkkoturvallisuuden, pääsynhallinnan, poikkeamien käsittelyn ja liiketoiminnan jatkuvuuden. DORA:n osalta se viittaa ICT-riskien hallintaan, tietoturvapoikkeamiin reagointiin, raportointiin ja ICT-kolmansien osapuolten valvontaan.
Tämä on Clarysec-menetelmän ydin: yksi ISMS, yksi riskirekisteri, yksi SoA, yksi näyttökirjasto ja useita vaatimustenmukaisuustuloksia.
Zenith Controls: The Cross-Compliance Guide Zenith Controls tukee tätä auttamalla organisaatioita käyttämään ISO/IEC 27002:2022:n ISO/IEC 27002:2022 kontrolliaiheita ristikkäisen vaatimustenmukaisuuden ankkureina. GDPR Article 32:n kannalta tärkeimpiä ankkureita ovat usein Privacy and Protection of PII, kontrolli 5.34; Independent Review of Information Security, kontrolli 5.35; ja Use of Cryptography, kontrolli 8.24.
| ISO/IEC 27002:2022 -kontrolliankkuri Zenith Controlsissa | Miksi sillä on merkitystä Article 32:n TOMs-toimenpiteille | Esimerkkejä näytöstä |
|---|---|---|
| 5.34 Privacy and Protection of PII | Yhdistää tietoturvakontrollit henkilötietojen käsittelyyn ja tietosuojavelvoitteisiin | Tietoaineistorekisteri, tietosuojariskien arviointi, säilytysaikataulu, DPA-sopimukset, käyttöoikeuskatselmoinnit |
| 5.35 Independent Review of Information Security | Osoittaa objektiivisen varmentamisen, auditoitavuuden ja parantamisen | Sisäisen tarkastuksen raportti, ulkoinen arviointi, korjaavien toimenpiteiden loki, johdon katselmointi |
| 8.24 Use of Cryptography | Suojaa siirrettävien, lepotilassa olevien ja varmuuskopioissa olevien tietojen luottamuksellisuutta ja eheyttä | Salausstandardi, avaintenhallinnan tallenteet, levysalausnäyttö, TLS-konfiguraatio, varmuuskopioiden salaus |
NIS2 tekee TOMs-toimenpiteistä hallitustason kyberturvallisuuskysymyksen
Monet organisaatiot pitävät GDPR:n TOMs-toimenpiteitä tietosuojatiimin vastuuna. NIS2 muuttaa keskustelun.
NIS2 koskee monia lueteltujen toimialojen keskisuuria ja suuria toimijoita sekä joissakin tapauksissa toimijoita koosta riippumatta. Soveltamisalaan kuuluvia digitaalisia ja teknologia-aloja ovat pilvipalveluntarjoajat, datakeskuspalveluntarjoajat, sisällönjakeluverkot, DNS-palveluntarjoajat, TLD-rekisterit, luottamuspalveluntarjoajat, yleisten sähköisten viestintäpalvelujen tarjoajat, hallinnoidut palveluntarjoajat, hallinnoidut tietoturvapalveluntarjoajat, verkkomarkkinapaikat, hakukoneet ja sosiaalisen verkostoitumisen alustat. SaaS- ja teknologia-alan pk-yritysten soveltuvuus riippuu toimialasta, koosta, jäsenvaltion nimeämisestä sekä systeemisestä tai rajat ylittävästä vaikutuksesta.
NIS2 Article 20 asettaa kyberturvallisuusvastuun johtoelimille. Niiden on hyväksyttävä kyberturvallisuuden riskienhallintatoimenpiteet, valvottava toteutusta ja osallistuttava koulutukseen. Keskeisille toimijoille voidaan määrätä hallinnollisia sakkoja, joiden vähimmäistaso on 10 miljoonaa euroa tai vähintään 2 prosenttia maailmanlaajuisesta vuotuisesta liikevaihdosta. Tärkeille toimijoille voidaan määrätä sakkoja, joiden vähimmäistaso on 7 miljoonaa euroa tai vähintään 1,4 prosenttia.
NIS2 Article 21 liittyy suoraan Article 32:n TOMs-toimenpiteisiin, koska se edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä. Toimenpiteissä on otettava huomioon tekniikan taso, eurooppalaiset ja kansainväliset standardit, kustannukset, altistuminen, koko, todennäköisyys, vakavuus sekä yhteiskunnallinen tai taloudellinen vaikutus. Vaadittuja osa-alueita ovat riskianalyysi, tietoturvapolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta ja kehittäminen, haavoittuvuuksien käsittely, vaikuttavuuden arviointi, kyberhygienia, koulutus, kryptografia, HR-turvallisuus, pääsynhallinta, omaisuudenhallinta, MFA tai jatkuva todennus sekä turvallinen viestintä soveltuvin osin.
NIS2 Article 23 lisää vaiheistetun poikkeamaraportoinnin: ennakkovaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa, välipäivitykset pyynnöstä ja loppuraportti viimeistään kuukauden kuluttua 72 tunnin ilmoituksesta. Jos henkilötietojen tietoturvaloukkaus täyttää myös NIS2:n merkittävän poikkeaman kriteerit, näyttökokonaisuuden on tuettava sekä tietosuojaan että kyberturvallisuuteen liittyviä raportointipäätöksiä.
DORA nostaa rimaa rahoitusalan häiriönsietokyvylle ja ICT-palveluntarjoajille
DORA:a sovelletaan 17. tammuta 2025 alkaen, ja se luo rahoitusalalle sääntökirjan digitaalisesta operatiivisesta häiriönsietokyvystä. Se kattaa ICT-riskien hallinnan, merkittävien ICT:hen liittyvien poikkeamien raportoinnin, operatiivisen häiriönsietokyvyn testauksen, kyberuhkia ja haavoittuvuuksia koskevan tiedonjaon, ICT-kolmansien osapuolten riskin, ICT-palveluntarjoajia koskevat sopimusvaatimukset, kriittisten ICT-kolmannen osapuolen palveluntarjoajien valvonnan ja viranomaisvalvonnan.
Niiden rahoitusalan toimijoiden osalta, jotka on myös tunnistettu kansallisten NIS2-sääntöjen nojalla, DORA toimii sektorikohtaisena unionin säädöksenä päällekkäisissä kyberturvallisuuden riskienhallinnan ja poikkeamaraportoinnin velvoitteissa. Käytännössä soveltamisalaan kuuluvien rahoitusalan toimijoiden tulee priorisoida DORA:a näillä päällekkäisillä osa-alueilla ja ylläpitää samalla koordinaatiota NIS2:n toimivaltaisten viranomaisten ja CSIRT-toimijoiden kanssa soveltuvin osin.
GDPR Article 32:n näytön kannalta DORA:lla on merkitystä kahdella tavalla. Ensinnäkin fintech-yritykset voivat kuulua suoraan soveltamisalaan rahoitusalan toimijoina, mukaan lukien luottolaitokset, maksulaitokset, tilitietopalveluntarjoajat, sähköisen rahan laitokset, sijoituspalveluyritykset, kryptovarapalveluntarjoajat, kaupankäyntipaikat ja joukkorahoituspalvelujen tarjoajat. Toiseksi SaaS-, pilvi-, data-, ohjelmisto- ja hallinnoidut palveluntarjoajat voivat rahoitusalan asiakkaiden näkökulmasta olla ICT-kolmannen osapuolen palveluntarjoajia, koska DORA määrittelee ICT-palvelut laajasti.
DORA Article 5 edellyttää ICT-riskien hallinnalta hallinnointia ja sisäisiä kontrolleja siten, että johtoelin määrittää, hyväksyy ja valvoo ICT-riskijärjestelyjä ja pysyy niistä vastuussa. Article 6 edellyttää dokumentoitua ICT-riskienhallinnan viitekehystä, johon sisältyvät strategiat, politiikat, menettelyt, ICT-protokollat ja työkalut tietojen ja ICT-omaisuuserien suojaamiseksi. Article 17 edellyttää ICT:hen liittyvien poikkeamien hallintaprosessia, joka kattaa havaitsemisen, hallinnan, ilmoittamisen, kirjaamisen, juurisyyn, ennakkovaroitusindikaattorit, luokittelun, roolit, viestinnän, eskaloinnin ja reagoinnin. Article 19 edellyttää merkittävien ICT:hen liittyvien poikkeamien ilmoittamista toimivaltaisille viranomaisille.
DORA Articles 28 ja 30 tekevät ICT-kolmansien osapuolten riskistä säännellyn kontrollialueen. Rahoitusalan toimijat ovat edelleen vastuussa vaatimustenmukaisuudesta käyttäessään ICT-palveluja. Ne tarvitsevat kolmannen osapuolen riskistrategian, sopimusrekisterit, kriittisyysarvioinnit, huolellisuusarvioinnin, keskittymäriskin tarkastelun, auditointi- ja tarkastusoikeudet, päättämisperusteet, exit-strategiat sekä sopimusmääräykset, jotka kattavat tietojen sijainnit, saatavuuden, aitouden, eheyden, luottamuksellisuuden, poikkeama-avun, palautumisen, palvelutasot ja yhteistyön viranomaisten kanssa.
Article 32:n osalta tämä tarkoittaa, että toimittajat ovat osa TOMs-kokonaisuutta. Käsittelyn turvallisuutta ei voida osoittaa, jos kriittisiä käsittelijöitä, pilvialustoja, analytiikkapalveluntarjoajia, tukityökaluja ja ICT-palveluntarjoajia ei kontrolloida.
Käytännön yhden viikon Article 32 -näytön rakentaminen
Vahva näyttökokonaisuus alkaa yhdestä selkeästä riskiskenaariosta.
Käytä tätä esimerkkiä: ”Luvaton pääsy asiakkaiden henkilötietoihin tuotantosovelluksessa.”
Luo tai päivitä riskimerkintä. Sisällytä kuvaus, todennäköisyys, vaikutus, pisteet, omistaja ja riskienkäsittelysuunnitelma. Nimeä omistajaksi kehitysjohtaja, tietoturvapäällikkö tai vastaava vastuullinen rooli. Arvioi todennäköisyys käyttöoikeusmallin, altistuneen hyökkäyspinnan, tunnettujen haavoittuvuuksien ja aiempien poikkeamien perusteella. Arvioi vaikutus henkilötietojen määrän, arkaluonteisuuden, asiakassopimusten, GDPR-seuraamusten sekä mahdollisen NIS2- tai DORA-palveluvaikutuksen perusteella.
Valitse käsittelytoimet, kuten MFA etuoikeutetulle pääsylle, roolipohjainen käyttöoikeuksien hallinta, neljännesvuosittaiset käyttöoikeuskatselmoinnit, lepotilassa olevien tietojen salaus, TLS, haavoittuvuusskannaus, lokitus, hälyttäminen, turvallinen varmuuskopiointi, tietoturvapoikkeamiin reagoinnin menettelyt ja tietojen maskaus ei-tuotantoympäristöissä.
Kartoita sen jälkeen riski SoA:han. Lisää ISO/IEC 27002:2022 -viittaukset, kuten 5.34 Privacy and Protection of PII, 8.24 Use of Cryptography, 5.15 Access Control, 5.18 Access Rights, 8.13 Information Backup, 8.15 Logging, 8.16 Monitoring Activities, 8.8 Management of Technical Vulnerabilities, 8.25 Secure Development Life Cycle ja 8.10 Information Deletion soveltuvin osin. Lisää huomautuksia siitä, miten nämä kontrollit tukevat GDPR Article 32:ta, NIS2 Article 21:tä ja DORA:n ICT-riskien hallintaa soveltuvissa kohdissa.
Sääntelykartoituksessa kontrollien nimet on pidettävä täsmällisinä eikä vääriä vastaavuuksia tule pakottaa.
| ISO/IEC 27002:2022 -kontrolli | Kontrollin nimi | Miksi sisällytetty | Sääntelykartoitus |
|---|---|---|---|
| 8.24 | Use of Cryptography | Suojaa siirrettävien, lepotilassa olevien ja varmuuskopioissa olevien henkilötietojen luottamuksellisuutta ja eheyttä | GDPR Art. 32; NIS2 Art. 21(2)(h) |
| 5.20 | Addressing information security within supplier agreements | Varmistaa, että toimittajien tietoturvavelvoitteet on määritelty sopimuksissa ja että ne ovat sitovia | GDPR:n käsittelijäkontrollit; NIS2 Art. 21(2)(d); DORA Art. 28 ja Art. 30 |
| 5.24 | Information security incident management planning and preparation | Luo valmiuden havaitsemiseen, eskalointiin, arviointiin ja raportointiin | GDPR:n loukkauksia koskeva osoitusvelvollisuus; NIS2 Art. 23; DORA Art. 17 ja Art. 19 |
| 8.13 | Information Backup | Tukee saatavuutta, palauttamista ja häiriönsietokykyä häiriön tai tietojen menetyksen jälkeen | GDPR Art. 32; NIS2 Art. 21(2)(c); DORA:n ICT-jatkuvuusodotukset |
| 8.10 | Information Deletion | Tukee turvallista hävittämistä, säilytysvaatimusten soveltamista ja tietojen minimointia | GDPR:n säilytyksen rajoittaminen ja Art. 32; asiakkaiden sopimusvaatimukset |
Rakenna seuraavaksi näyttökansio. Clarysecin pk-yritysten auditointi- ja vaatimustenmukaisuuden seurantapolitiikka antaa yksinkertaisen säännön:
”Kaikki näyttö on säilytettävä keskitettyyn auditointikansioon.”
Lähde: Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille, politiikan toteutusvaatimukset, politiikan kohta 6.2.1. Audit and Compliance Monitoring Policy - SME
Tämän yhden riskiskenaarion osalta kansion tulee sisältää:
| Näyttökohde | Mitä säilytetään | Miksi sillä on merkitystä |
|---|---|---|
| Riskimerkintä | Riskin kuvaus, omistaja, pisteytys, käsittelysuunnitelma ja jäännösriskipäätös | Osoittaa TOMs-toimenpiteiden riskiperusteisen valinnan |
| SoA-ote | Soveltuvat kontrollit sekä GDPR-, NIS2- ja DORA-huomiot | Osoittaa jäljitettävyyden riskistä kontrolliin |
| Käyttöoikeuskatselmointi | Katselmoidut käyttäjät, päätökset, poistot ja poikkeukset | Osoittaa pääsynhallinnan toiminnan |
| MFA-raportti | Vienti, joka osoittaa MFA:n käyttöönoton etuoikeutetuille käyttäjille | Tukee todennusnäyttöä |
| Salausnäyttö | Konfiguraatiotallenne, arkkitehtuurihuomio tai avaintenhallinnan tallenne | Tukee luottamuksellisuutta ja eheyttä |
| Haavoittuvuustallenne | Viimeisin skannaus, korjaavat tiketit ja hyväksytyt poikkeukset | Tukee teknisen riskin vähentämistä |
| Lokitusnäyttö | SIEM-tapahtumanäyte, hälytyssääntö ja säilytysasetus | Tukee havaitsemista ja tutkintaa |
| Varmuuskopiotesti | Palautustestin tulos ja varmuuskopioinnin kattavuustallenne | Tukee saatavuutta ja häiriönsietokykyä |
| Poikkeamaharjoitus | Pöytäharjoituksen muistiinpanot, testipoikkeamaloki tai opittujen asioiden tallenne | Tukee reagointivalmiutta |
| Johdon hyväksyntä | Kokouspöytäkirja, hyväksyntä tai riskin hyväksymistallenne | Tukee osoitusvelvollisuutta ja oikeasuhtaisuutta |
Käyttöoikeusnäyttö ei saa rajoittua kuvakaappauksiin. Pk-yritysten pääsynhallintapolitiikka lisää hyödyllisen operatiivisen vaatimuksen:
”IT-päällikön on dokumentoitava katselmointitulokset ja korjaavat toimenpiteet.”
Lähde: Pääsynhallintapolitiikka pk-yrityksille, hallinnointivaatimukset, politiikan kohta 5.5.3. Access Control Policy - SME
Varmuuskopiointinäytön on osoitettava palautuskelpoisuus, ei pelkästään onnistuneita ajoja. Pk-yritysten varmuuskopiointi- ja palautuspolitiikka toteaa:
”Palautustestit suoritetaan vähintään neljännesvuosittain, ja tulokset dokumentoidaan palautuskelpoisuuden varmentamiseksi”
Lähde: Varmuuskopiointi- ja palautuspolitiikka pk-yrityksille, hallinnointivaatimukset, politiikan kohta 5.3.3. Backup and Restore Policy - SME
Näin muodostuu täydellinen näyttöketju: sääntely luo vaatimuksen, riski selittää sen merkityksen, SoA valitsee kontrollin, politiikka määrittää toiminnan ja säilytetty näyttö osoittaa kontrollin toimivuuden.
Kontrollit käytännössä: politiikasta toiminnan näytöksi
Zenith Blueprintin Controls in Action -vaiheen Step 19 keskittyy tekniseen varmennukseen. Se suosittelee katselmoimaan päätelaiteturvallisuuden vaatimustenmukaisuuden, identiteetin- ja pääsynhallinnan, todentamismääritykset, lähdekoodinhallinnan turvallisuuden, kapasiteetin ja saatavuuden, haavoittuvuuksien ja korjauspäivitysten hallinnan, turvalliset perustasot, haittaohjelmasuojauksen, poistamisen ja tietojen minimoinnin, maskauksen ja testidatan, DLP:n, varmuuskopioinnin ja palautuksen, redundanssin, lokituksen ja valvonnan sekä aikasynkronoinnin.
GDPR Article 32:n TOMs-toimenpiteissä Step 19 on kohta, jossa abstrakti kontrollikieli muuttuu näytöksi. Vahvan näyttökokonaisuuden tulee osoittaa, että:
- Päätelaitteiden salaus on käytössä ja sitä valvotaan.
- Etuoikeutetuilla käyttäjillä on MFA.
- JML-prosessit täsmäytetään HR-tallenteisiin.
- Palvelutilit on dokumentoitu ja rajoitettu.
- Kooditietovarastojen pääsyä hallitaan ja salaisuuksien skannaus suoritetaan.
- Haavoittuvuusskannaukset tehdään ja korjausta seurataan.
- Tuotantodataa ei kopioida huolimattomasti testiympäristöihin.
- Turvallisen poistamisen ja säilytyksen politiikat pannaan täytäntöön.
- DLP-hälytykset katselmoidaan.
- Varmuuskopioiden palautustestit osoittavat palautuskelpoisuuden.
- Lokit keskitetään, säilytetään ja ne ovat katselmoitavissa.
- Aikasynkronointi tukee luotettavaa poikkeamatutkintaa.
Avain on yhteys. Korjauspäivitysraportti ilman riski-, politiikka- ja SoA-viitettä on IT-artefakti. Korjauspäivitysraportti, joka on kytketty GDPR Article 32:een, NIS2 Article 21:een, DORA:n ICT-riskien hallintaan ja ISO 27001:2022:n riskienkäsittelysuunnitelmaan, on auditointivalmista näyttöä.
Yksi näyttökokonaisuus, useita auditointinäkökulmia
Eri sidosryhmät lukevat samaa TOMs-näyttöä eri tavoin. Tietosuojakatselmoija voi keskittyä henkilötietoihin, tarpeellisuuteen, oikeasuhtaisuuteen ja osoitusvelvollisuuteen. ISO 27001 -auditoija voi keskittyä soveltamisalaan, riskien käsittelyyn, SoA:han ja toiminnan näyttöön. NIS2-viranomainen voi keskittyä johdon valvontaan, Article 21:n toimenpiteisiin ja Article 23:n raportointivalmiuteen. DORA-valvoja tai rahoitusalan asiakas voi keskittyä ICT-riskien hallinnointiin, häiriönsietokyvyn testaukseen ja kolmannen osapuolen riippuvuuksiin.
Clarysec käyttää Zenith Controls -opasta tämän tulkinnan ristikkäisen vaatimustenmukaisuuden oppaana.
| Kohderyhmä | Mitä he kysyvät | Miten näytön tulee vastata |
|---|---|---|
| GDPR:n tietosuojakatselmoija | Ovatko TOMs-toimenpiteet henkilötietoriskiin nähden asianmukaisia ja voidaanko osoitusvelvollisuus osoittaa? | Riskirekisteri, tietoaineistorekisteri, tietosuojakontrollit, säilytystallenteet, pääsyrajoitukset, salausnäyttö ja loukkausarviointien tallenteet |
| ISO 27001:2022 -auditoija | Onko ISMS:n soveltamisala määritelty ja onko se riskiperusteinen, toteutettu, seurattu ja parannettu? | Soveltamisala, riskimenetelmä, SoA, sisäinen tarkastus, johdon katselmointi ja korjaavat toimenpiteet |
| NIS2-katselmoija | Onko kyberturvallisuustoimenpiteet hyväksytty, ovatko ne oikeasuhtaisia ja kattavatko ne Article 21:n osa-alueet? | Hallituksen hyväksyntä, tietoturvapolitiikat, poikkeamien käsittely, jatkuvuus, toimittajariski, koulutus, MFA ja haavoittuvuuksien hallinta |
| DORA-valvoja tai rahoitusalan asiakas | Onko ICT-riski hallinnoitu, testattu ja häiriönsietokykyinen, mukaan lukien ICT-kolmannen osapuolen riski? | ICT-riskienhallinnan viitekehys, häiriönsietokyvyn strategia, poikkeamaprosessi, testausnäyttö, toimittajarekisteri ja exit-suunnitelmat |
| NIST-suuntautunut arvioija | Pystyykö organisaatio tunnistamaan, suojaamaan, havaitsemaan, reagoimaan ja palautumaan toistettavan näytön avulla? | Omaisuus- ja tietoaineistorekisteri, suojauskontrollit, seurantatallenteet, reagointilokit ja palautustestit |
| COBIT 2019- tai ISACA-auditoija | Onko hallinnointi vastuutettu, mitattu ja linjassa yrityksen tavoitteiden kanssa? | Roolit, johdon raportointi, riskinottohalukkuus, suorituskykymittarit, varmennustulokset ja parantamistoimet |
Tämä estää päällekkäisen vaatimustenmukaisuustyön. Sen sijaan, että rakennetaan erilliset näyttöpaketit GDPR:lle, NIS2:lle ja DORA:lle, rakennetaan yksi kontrollinäyttökokonaisuus ja merkitään jokainen kohde niiden velvoitteiden mukaan, joita se tukee.
Yleiset puutteet Article 32:n TOMs-ohjelmissa
Yleisin puute on kontrollien irtoaminen kontekstistaan. Yrityksellä on kontrolli, kuten salaus, mutta se ei pysty selittämään, mitä riskiä se käsittelee, mikä politiikka sitä edellyttää, kuka sen omistaa tai miten se katselmoidaan.
Toinen puute on heikko toimittajanäyttö. GDPR:n mukaan käsittelijöillä ja alikäsittelijöillä on merkitystä. NIS2:n mukaan toimitusketjun turvallisuus on osa kyberturvallisuuden riskienhallintaa. DORA:n mukaan ICT-kolmannen osapuolen riski on säännelty osa-alue, johon kuuluvat rekisterit, huolellisuusarviointi, sopimusperusteiset suojatoimet, auditointioikeudet ja exit-suunnittelu. Toimittajataulukko ei riitä, jos kriittisiä riippuvuuksia ei riskinarvioida ja kontrolloida.
Kolmas puute on poikkeamanäyttö. Organisaatioilla on usein tietoturvapoikkeamiin reagointisuunnitelma, mutta ei näyttöä siitä, että luokittelu, eskalointi, viranomaisraportointi ja asiakasviestintä on testattu. NIS2 ja DORA nostavat odotuksia tällä alueella, ja GDPR:n henkilötietojen tietoturvaloukkauksen arviointi on integroitava samaan työnkulkuun.
Neljäs puute on varmuuskopiointinäyttö. Onnistunut varmuuskopiointiajo ei osoita palautuskelpoisuutta. Dokumentoitu palautustesti osoittaa.
Viides puute on johdon katselmointi. Article 32:n TOMs-toimenpiteiden on oltava riskiin nähden oikeasuhtaisia. Jos johto ei koskaan katselmoi riskejä, poikkeamia, toimittajaongelmia, budjettia, auditointihavaintoja ja jäännösriskiä, oikeasuhtaisuutta on vaikea osoittaa.
Lopullinen auditointivalmis työkalupaketti
Zenith Blueprintin Audit, Review and Improvement -vaiheen Step 30 tarjoaa lopullisen valmiuden tarkistuslistan. Se sisältää ISMS:n soveltamisalan ja toimintaympäristön, allekirjoitetun tietoturvapolitiikan, riskien arviointi- ja käsittelyasiakirjat, SoA:n, liite A:n politiikat ja menettelyt, koulutussuoritustiedot, operatiiviset tallenteet, sisäisen tarkastuksen raportin, korjaavien toimenpiteiden lokin, johdon katselmointipöytäkirjat, jatkuvan parantamisen näytön ja vaatimustenmukaisuusvelvoitteiden tallenteet.
Clarysecin yritystason auditointi- ja vaatimustenmukaisuuden seurantapolitiikka määrittää tämän kurinalaisuuden tarkoituksen:
”Tuottaa puolustettavaa näyttöä ja auditointijälki sääntelyyn liittyvien tiedustelujen, oikeudellisten menettelyjen tai asiakkaiden varmentamispyyntöjen tueksi.”
Lähde: Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka, tavoitteet, politiikan kohta 3.4. Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka
Kypsän Article 32:n TOMs-näyttökokonaisuuden tulee sisältää:
| Näyttöluokka | Auditointivalmis vähimmäissisältö |
|---|---|
| Hallinnointi | ISMS:n soveltamisala, politiikan hyväksyntä, roolit, tavoitteet, johdon katselmointipöytäkirjat |
| Riski | Riskimenetelmä, riskirekisteri, käsittelysuunnitelma, jäännösriskien hyväksynnät |
| SoA | Soveltuvat kontrollit, poissulkemiset, perustelut ja sääntelykartoitus |
| Tietosuoja | Tietoaineistorekisteri, henkilötietokontrollit, säilytysnäyttö, DPIA tai tietosuojariskien arviointi soveltuvin osin |
| Tekniset kontrollit | MFA, käyttöoikeuskatselmoinnit, salaus, haavoittuvuuksien hallinta, lokitus, valvonta ja turvallisen kehittämisen näyttö |
| Häiriönsietokyky | Varmuuskopioinnin kattavuus, palautustestit, jatkuvuussuunnitelmat, poikkeamaharjoitukset ja palautumismittarit |
| Toimittajavarmennus | Toimittajarekisteri, huolellisuusarviointi, sopimuslausekkeet, seuranta, auditointioikeudet ja exit-suunnittelu |
| Parantaminen | Sisäiset tarkastukset, korjaavat toimenpiteet, opitut asiat ja kontrollien tehokkuuden katselmoinnit |
Seuraavat vaiheet: rakenna Article 32:n TOMs-näyttö Clarysecin avulla
Jos sinun on osoitettava GDPR Article 32:n tekniset ja organisatoriset toimenpiteet, älä aloita keräämällä satunnaisia kuvakaappauksia. Aloita jäljitettävyydestä.
- Määritä ISMS:n soveltamisala ja henkilötietojen käsittelyn rajat.
- Tunnista GDPR-, NIS2-, DORA-, sopimus- ja asiakasvaatimukset.
- Rakenna riskikriteerit ISO/IEC 27005:2022:n ja johdon hyväksymän riskinottohalukkuuden perusteella.
- Luo tai päivitä riskirekisteri.
- Kartoita jokainen käsittelytoimi ISO 27001:2022 -kontrolleihin ja SoA:han.
- Käytä Zenith Controls -opasta tietosuoja-, kryptografia-, toimittaja-, poikkeama- ja riippumattoman katselmoinnin kontrollien ristiviittauksiin eri vaatimustenmukaisuusodotusten välillä.
- Noudata Zenith Blueprintin Step 13:ta ja Step 14:ää riskien, kontrollien ja sääntelyvelvoitteiden yhdistämiseksi.
- Käytä Zenith Blueprintin Step 19:ää teknisten kontrollien toiminnan varmentamiseen.
- Käytä Zenith Blueprintin Step 30:tä lopullisen auditointivalmiin näyttökokonaisuuden kokoamiseen.
- Säilytä kaikki näyttö keskitetysti, merkitse se riskin ja kontrolliteeman mukaan ja pidä korjaavat toimenpiteet näkyvillä.
Clarysec voi auttaa muuttamaan GDPR Article 32:n epämääräisestä vaatimustenmukaisuusvelvoitteesta puolustettavaksi, riskiperusteiseksi näyttöjärjestelmäksi, joka on linjassa ISO 27001:2022:n, NIS2:n ja DORA:n kanssa.
Aloita Zenith Blueprint -oppaasta, vahvista sitä Clarysecin politiikoilla ja käytä Zenith Controls -opasta tehdäksesi jokaisesta TOMs-toimenpiteestä jäljitettävän, testattavan ja auditointivalmiin.
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
