Tietojen luokittelu ISO 27001:n, GDPR:n, NIS2:n ja DORA:n näkökulmasta

Vuoden 2026 auditointihetki: ”Näyttäkää auditointinäyttö”

On helmikuu 2026, eikä nopeasti kasvavan fintech-SaaS-yhtiön neljännesvuosittainen hallituksen kokous etene niin sujuvasti kuin tietoturvajohtaja odotti.

Yhtiö on hiljattain saavuttanut ISO/IEC 27001:2022 -sertifioinnin. Käytössä ovat MFA, päätelaitesuojaus, haavoittuvuusskannaukset, käyttöoikeuskatselmoinnit, tietoturvapoikkeamiin reagoinnin menettelyt ja viimeistelty DORA-valmiusraportti. Sitten toimitusjohtaja esittää kysymyksen, joka muuttaa kokouksen sävyn.

”Pääsijoittajamme kysyy, miten voimme osoittaa, että asiakkaiden taloustietoja suojataan yhdenmukaisesti AWS:ssä, Azuressa, SaaS-tukialustallamme ja analytiikkatietovarastossa. Jos auditoija poimii yhden tiedoston objektitallennuksesta ja toisen yhteistyökansiosta, mistä tiedämme, että niihin sovelletaan samoja sääntöjä?”

Tietoturvajohtaja avaa omaisuusrekisterin. Siinä luetellaan tietokannat, pilvitilit, sovellukset, SaaS-alustat ja tallennussijainnit. Luokittelukenttä on kuitenkin puutteellinen. Osa kansioista on nimetty osaston, ei arkaluonteisuuden mukaan. Asiakasvientitiedostot ovat samassa sijainnissa sisäisten raportointitiedostojen kanssa. Osa tukitoimintojen laskentataulukoista sisältää asiakastunnisteita, maksuviitteitä ja tapausmuistiinpanoja, mutta ne on merkitty ”Sisäinen”-tasolle. DLP-säännöt ovat olemassa, mutta ne käynnistyvät vain ilmeisistä malleista. Pilvipolitiikan mukaan EU:n henkilötietojen on pysyttävä hyväksytyillä alueilla, mutta tiimi ei pysty osoittamaan, että tietojen sijaintia koskevat säännöt perustuvat luokittelumetatietoihin.

Tämän jälkeen vaatimustenmukaisuuspäällikkö lisää sääntelynäkökulman: ”Riittääkö tämä auditointinäytöksi GDPR Article 32:n, NIS2 Article 21:n ja DORA:n ICT-riskienhallinnan kannalta?”

Rehellinen vastaus on: ei vielä.

Tämä on vuoden 2026 puute, jonka monet organisaatiot kohtaavat. Niillä on tietoturvakontrollit, mutta ei hallintakerrosta, joka kertoo jokaiselle kontrollille, mitä suojataan, kuinka vahvasti sitä suojataan ja miten suojaus voidaan osoittaa. Tämä hallintakerros on tietojen luokittelu ja tietojen merkintä.

ISO/IEC 27001:2022:n näkökulmasta luokittelu ja merkintä eivät ole kosmeettisia asiakirjahallinnan käytäntöjä. Ne ovat käytännön silta riskien arvioinnin, pääsynhallinnan, salauksen, säilytyksen, DLP:n, pilvipalvelujen tietojen sijainnin, toimittajiin liittyvän due diligence -arvioinnin, seurannan ja poikkeamien ilmoittamisen välillä. Clarysecin toteutusmallissa ne ovat ISMS:n auditointinäyttöketjun ytimessä: inventoi omaisuuserä, nimeä omistaja, luokittele se, merkitse se, sovella käsittelysääntöjä, seuraa poikkeuksia ja osoita auditoijille jäljitettävyys.

Miksi luokittelu ja merkintä ovat nyt hallitustason kontrolleja

Viranomaiset ja asiakkaat odottavat yhä useammin, että organisaatiot osoittavat turvallisuustoimenpiteidensä olevan oikeassa suhteessa tietojen arkaluonteisuuteen, palvelun kriittisyyteen ja häiriön liiketoimintavaikutukseen.

GDPR tekee tämän nimenomaiseksi osoitusvelvollisuuden kautta. Article 5 edellyttää, että henkilötietoja käsitellään lainmukaisesti, kohtuullisesti ja läpinäkyvästi, käsittely rajoitetaan tarpeelliseen, tietoja säilytetään vain niin kauan kuin on tarpeen ja niitä suojataan asianmukaisilla teknisillä ja organisatorisilla toimenpiteillä. Rekisterinpitäjän on myös pystyttävä osoittamaan vaatimustenmukaisuus. GDPR Article 32:n todentaminen muuttuu vaikeaksi, ellei tiedetä, mitkä järjestelmät käsittelevät henkilötietoja, mitkä tiedot ovat korkean riskin tietoja tai erityisiin henkilötietoryhmiin kuuluvia tietoja, missä niitä säilytetään ja mitä suojatoimia sovelletaan.

NIS2 nostaa hallinnoinnin vaatimustasoa. Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat niiden toteutusta ja saavat koulutusta. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, kuten riskianalyysiä, turvallisuuspolitiikkoja, poikkeamien käsittelyä, liiketoiminnan jatkuvuutta, toimitusketjun turvallisuutta, hankinnan ja kehittämisen aikaista tietoturvaa, vaikuttavuuden arviointia, kyberhygieniaa, koulutusta, kryptografiaa, henkilöstöturvallisuutta, pääsynhallintaa ja omaisuudenhallintaa. Luokittelu ei ole tässä luettelossa erillinen tarkistuskohta. Se on päätöksentekomekanismi, joka mitoittaa toimenpiteet oikeasuhtaisiksi.

DORA soveltaa samaa logiikkaa finanssiyhteisöihin ja fintech-ekosysteemeihin. DORA on 17. tammikuuta 2025 alkaen edellyttänyt dokumentoitua ICT-riskienhallintakehystä, johtoelimen vastuuta, luottamuksellisuutta, eheyttä, saatavuutta ja aitoutta koskevia politiikkoja, poikkeamien luokittelua, häiriönsietokyvyn testausta ja ICT-kolmansien osapuolten riskienhallintaa. DORA:n soveltamisalaan kuuluvien finanssiyhteisöjen osalta DORA voi toimia sektorikohtaisena unionin säädöksenä päällekkäisten NIS2-riskienhallinta- ja raportointivelvoitteiden sijasta, mutta auditointinäyttöä koskeva odotus säilyy samana: osoita, miten kriittiset tiedot ja ICT-omaisuuserät tunnistetaan, suojataan, testataan, miten niitä seurataan ja miten niitä hallitaan.

ISO/IEC 27001:2022 soveltuu hyvin tämän auditointinäytön käyttöjärjestelmäksi. Kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää sisäiset ja ulkoiset tekijät, sidosryhmien vaatimukset, sääntely- ja sopimusvelvoitteet sekä rajapinnat muihin organisaatioihin. Kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, hallintakeinojen valintaa, soveltuvuuslausuntoa ja säilytettävää dokumentoitua tietoa. ISO/IEC 27001:2022

Jos GDPR, NIS2 ja DORA kysyvät: ”Miksi sovelsitte näitä toimenpiteitä?”, ISO/IEC 27001:2022 auttaa vastaamaan: ”Koska nämä omaisuuserät, tietotyypit, riskit, velvoitteet ja riskinkäsittelypäätökset johtivat tähän.”

Luokittelu on riskipäätös. Merkintä on operatiivinen signaali.

Clarysec erottaa luokittelun ja merkinnän toisistaan, koska auditoijatkin tekevät niin.

Luokittelu tarkoittaa päätöstä tiedon arkaluonteisuudesta, arvosta ja kriittisyydestä. Merkintä tarkoittaa tämän päätöksen tekemistä näkyväksi, pysyväksi ja päivittäisessä toiminnassa sovellettavaksi.

Clarysecin Tiedon luokittelu- ja merkintäpolitiikka pk-yrityksille määrittää tarkoituksen selkeästi:

Tämä politiikka määrittää, miten kaikki organisaation käsittelemät tiedot on luokiteltava ja merkittävä, jotta niiden luottamuksellisuus, eheys ja saatavuus säilyvät koko niiden elinkaaren ajan.

Sama Tiedon luokittelu- ja merkintäpolitiikka pk-yrityksille edellyttää organisaatioita:

Varmistamaan, että jokainen tietoaineisto luokitellaan sen arkaluonteisuuden perusteella ja merkitään vastaavasti asianmukaisen käsittelyn, säilytyksen ja pääsyn ohjaamiseksi.

Yritysympäristöissä Clarysecin P13 Tiedon luokittelu- ja merkintäpolitiikka määrittää vähimmäisluokittelumallin:

Organisaation on ylläpidettävä standardoitua luokittelumallia, jossa tasot on määritelty selkeästi. Vähintään seuraavia luokittelutasoja on käytettävä: 5.1.1 Julkinen: Tieto, joka on tarkoitettu avoimeen julkaisuun ja rajoittamattomaan jakeluun 5.1.2 Sisäinen: Ei-julkinen liiketoimintatieto, jota ei ole tarkoitettu ulkoiseen julkaisuun 5.1.3 Luottamuksellinen: Arkaluonteinen liiketoiminta-, sopimus- tai asiakastieto, joka edellyttää tiukkaa pääsynhallintaa 5.1.4 Rajoitettu (tai Erittäin luottamuksellinen): Kriittinen tai sääntelyn alainen tieto, jonka luvaton paljastuminen voisi aiheuttaa merkittävää haittaa tai oikeudellista vastuuta

Tällä erolla on merkitystä. ”Luottamuksellinen”-luokitus voi edellyttää salausta, roolipohjaista pääsyä ja sopimuksellisia suojatoimia. ”Rajoitettu”-luokitus voi käynnistää MFA:n, tietoturvajohtajan hyväksynnän ulkoiselle jakamiselle, tehostetun lokituksen, vahvemman säilytyksen hallinnan, eriyttämisen ja poikkeamien ensisijaisen eskaloinnin.

Yritystason politiikka on täsmällinen operatiivisesta merkinnästä:

Kaikki tietovarat on merkittävä tavalla, joka on: 6.2.1.1 Pysyvä: ei helposti poistettavissa tai ohitettavissa 6.2.1.2 Näkyvä: käyttäjälle selkeä käyttöhetkellä 6.2.1.3 Koneluettava: metatietopohjaisia merkintöjä on tuettava mahdollisuuksien mukaan

Koneluettavat merkinnät ovat kohta, jossa ohjelma kypsyy tietoisuudesta kontrollien toimeenpanoksi. Jos merkinnät perustuvat metatietoihin, pilvialustat, DLP-järjestelmät, sähköpostiyhdyskäytävät, identiteettityökalut, SIEM-säännöt, CASB-alustat ja säilytyksen hallintaratkaisut voivat toimia niiden perusteella. Jos merkintä on vain asiakirjan alatunnisteessa, se voi auttaa käyttäjiä, mutta se ei voi luotettavasti soveltaa sääntöjä laajassa mittakaavassa.

Mihin luokittelu sijoittuu Clarysecin tiekartassa

Clarysecin Zenith Blueprint: auditoijan 30-vaiheinen tiekartta sijoittaa luokittelun riskienhallinnan elinkaaren alkuvaiheeseen, ei teknologian käyttöönoton jälkeiseksi tehtäväksi. Riskienhallintavaiheessa, vaiheessa 9 ”Omaisuuserien, uhkien ja haavoittuvuuksien tunnistaminen”, tiekartta ohjaa tiimejä inventoimaan tietovarat ja kirjaamaan omistajan, sijainnin ja luokituksen.

Tämä estää yleisen epäonnistumisen: pilvi-inventaario on olemassa, mutta tietoinventaariota ei. Tietokanta, SaaS-tenantti tai data warehouse on teknologiaomaisuuserä. Niiden sisältämät asiakastietueet, työntekijätiedot, maksulokit, mallien koulutustietoaineistot, tukikeskustelujen transkriptiot ja poikkeamiin liittyvä auditointinäyttö ovat tietovaroja. Luokittelu kuuluu tälle tietotasolle.

Zenith Blueprint -ohjeistus ISO/IEC 27002:2022 -hallintakeinosta 5.12, Tiedon luokittelu, selittää periaatteen:

Jokainen koskaan kirjoitettu tietoturvakontrolli, olipa kyse pääsyn rajoittamisesta, salauksesta, varmuuskopioinnista, seurannasta tai hävittämisestä, olettaa yhden asian: organisaatio tietää, mitä se suojaa. Hallintakeino 5.12 edellyttää, että tieto luokitellaan sen arvon, arkaluonteisuuden ja kriittisyyden perusteella, mikä muodostaa perustan kaikille myöhemmille ISMS:n päätöksille.

ISO/IEC 27002:2022 -hallintakeinon 5.13, Tiedon merkintä, osalta sama tiekartta muuntaa luokittelun päivittäiseksi toiminnaksi:

Merkintä on tapa muuttaa abstrakti politiikka operatiiviseksi todellisuudeksi. Se on hetki, jolloin käyttäjä näkee asiakirjan, sähköpostin, tietokantakentän tai tulostetun raportin ja pystyy yhdellä silmäyksellä päättelemään: mitä tämä tieto on, kuinka arkaluonteista se on ja miten sitä tulee käsitellä.

Viimeinen tiekarttayhteys näkyy vaiheessa 13, ”Riskienkäsittelysuunnittelu ja soveltuvuuslausunto”. Zenith Blueprint kuvaa SoA:n siltana riskien, käsittelytoimien ja hallintakeinojen välillä. Tässä luokittelusta tulee auditoinnin jäljitettävyyttä. Riskiskenaario, kuten ”asiakkaan taloustietojen luvaton paljastuminen jaetusta pilvitallennuksesta”, voidaan yhdistää luokitteluun, merkintään, pääsynhallintaan, salaukseen, lokitukseen, DLP:hen, pilvipalvelujen käyttöön, toimittajavaatimuksiin ja tietoturvapoikkeamiin reagointiin.

Kontrollisuhteet, joita auditoijat odottavat näkevänsä

Clarysecin Zenith Controls: vaatimustenmukaisuuden ristiinkartoitusopas kartoittaa ISO/IEC 27002:2022 -hallintakeinon 5.12, Tiedon luokittelu, ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se liitetään Identify-kyberturvallisuuskäsitteeseen, Information Protection -operatiiviseen kyvykkyyteen sekä Protection and Defense -tietoturva-alueisiin.

ISO/IEC 27002:2022 -hallintakeinon 5.13, Tiedon merkintä, osalta Zenith Controls kartoittaa kontrollin ennaltaehkäiseväksi, Protect-painotteiseksi kontrolliksi, jolla on samat tietoturvaominaisuudet ja Information Protection -operatiivinen kyvykkyys.

Keskeinen havainto on, että luokittelu ja merkintä eivät ole erillisiä. Ne tekevät ympäröivistä kontrolleista puolustettavissa olevia.

Zenith Controls kartoittaa hallintakeinon 5.12 GDPR Article 32:een ja Recital 83:een, NIS2 Article 21(2)(a):han ja 21(2)(f):ään, ISO/IEC 27701 Annex B:hen, NIST SP 800-53 MP-3:een ja PM-11:een, FIPS 199:ään ja NIST SP 800-60:een sekä COBIT 2019 DSS06.06:een ja APO13.01:een. Hallintakeino 5.13 kartoitetaan GDPR Article 32:een, NIS2 Article 21(2)(a):han ja 21(2)(f):ään, DORA Article 9(1):een ja 9(2):een, NIST SP 800-53 MP-3:een ja COBIT 2019 DSS06.06:een.

Tämä tarkoittaa, että yksi auditointinäytön kokonaisuus voi vastata useisiin varmennuskysymyksiin.

Omaisuusrekisterissä luokittelusta tulee auditointinäyttöä

Monet luokitteluohjelmat epäonnistuvat, koska luokittelumalli on olemassa vain politiikassa. Clarysecin lähestymistapa alkaa omaisuusluettelosta.

Clarysecin P12 Omaisuudenhallintapolitiikka edellyttää, että omaisuusluettelo sisältää luokittelutason vähimmäiskenttänä:

Omaisuusluettelon on sisällettävä vähintään: 5.3.1 omaisuuserän tunniste, luokka ja tyyppi 5.3.2 sarjanumero tai yksilöllinen tunniste (fyysisille omaisuuserille) 5.3.3 ohjelmistoversio tai lisenssiavain (ohjelmisto-omaisuuserille) 5.3.4 omaisuuserän omistaja 5.3.5 luokittelutaso (Julkinen, Sisäinen, Luottamuksellinen, Rajoitettu) 5.3.6 sijainti (fyysinen, virtuaalinen, pilvi) 5.3.7 elinkaaren tila (aktiivinen, huollossa, poistettu käytöstä)

Tämä vastaa suoraan ISO/IEC 27001:2022:n riskisuunnittelua. Jos tietovarojen, omistajan, sijainnin ja luokituksen tunnistaminen ei onnistu, todennäköisyyttä, vaikutusta, käsittelyn prioriteettia tai jäännösriskiä ei voida arvioida yhdenmukaisesti. Et myöskään voi luotettavasti päättää, vaikuttaako toimittajajärjestely, pilvipalvelu tai SaaS-integraatio sääntelyn alaiseen tietoon.

GDPR:n kannalta tämä tukee osoitusvelvollisuutta. Article 30:n käsittelytoimien selosteet ja Article 32:n turvallisuustoimenpiteet ovat uskottavampia, kun omaisuusrekisteri tunnistaa, missä henkilötietoja käsitellään ja miten niitä suojataan. DORA:n kannalta sama rekisteri tukee ICT-omaisuuden ja palvelujen kriittisyyttä, häiriönsietokyvyn testauksen soveltamisalaa ja kolmansien osapuolten riippuvuusanalyysiä. NIS2:n kannalta se tukee riskianalyysiä, pääsynhallintaa ja omaisuudenhallintaa.

Tällainen tallenne muuttaa auditoinnin sävyä. Sen sijaan, että organisaatio sanoo ”uskomme arkaluonteisten tietojen olevan suojattuja”, se voi osoittaa, mitä tiedot ovat, kuka ne omistaa, miksi ne ovat Rajoitettu-tasolla, mitä kontrolleja sovelletaan ja milloin kontrollit on viimeksi katselmoitu.

Merkintöjen on ohjattava pilvi- ja SaaS-käsittelysääntöjä

Suurin osa arkaluonteisista tiedoista liikkuu nykyisin pilvialustojen, SaaS-sovellusten, analytiikkaputkien ja yhteistyövälineiden kautta. Politiikka, joka kehottaa käyttäjiä ”käsittelemään luottamuksellisia tietoja huolellisesti”, ei riitä.

Clarysecin P27 Pilvipalvelujen käyttöpolitiikka yhdistää pilvipalvelujen käytön suoraan luokitteluun ja tietojen sijaintiin:

Tietojen luokittelu ja sijainti 6.6.1 Mitään tietoa ei saa siirtää pilvialustalle ilman Tiedon luokittelu- ja merkintäpolitiikan (P13) mukaista luokittelua. 6.6.2 Tietojen sijaintivaatimukset on varmistettava sopimuksellisesti (esim. vain EU:ssa tapahtuva tallennus GDPR:n sääntelyn alaisille tiedoille). 6.6.3 Rajat ylittävien tiedonsiirtojen on noudatettava GDPR Chapter V:tä ja soveltuvin osin DORA Article 28:aa.

Tällä on merkitystä, koska pilviriski syntyy usein käytännön työnkulkujen kautta. Tiimi vie tietoaineiston uuteen analytiikkatyökaluun. Myynti synkronoi asiakaslistoja automaatioalustalle. Kehittäjä kopioi tuotantodataa testiympäristöön. Ilman luokittelua ja merkintää nämä toimet eivät välttämättä käynnistä oikeudellista arviointia, tietoturvahyväksyntää tai toimittajatarkastuksia.

Tiedon luokittelu- ja merkintäpolitiikka pk-yrityksille tarjoaa pienemmille organisaatioille yksinkertaisen toteutusmallin:

Jaettujen kansioiden tai pilvitallennuspalvelujen on käytettävä kansionimiä tai tunnisteita luokituksen osoittamiseen (esim. ”/Clients_Confidential”).

Kypsissä ympäristöissä kansionimiä tulee täydentää koneluettavilla merkinnöillä, ehdollisen pääsyn politiikoilla, ulkoisen jakamisen estoilla, salauksella, säilytysmerkinnöillä, DLP-säännöillä ja lokituksella. Tavoite ei ole pelkästään merkitä tietoa. Tavoite on tehdä merkinnästä toiminnallinen.

”Rajoitettu”-merkintä voi käynnistää ulkoisen jakamisen estot, lepotilassa ja siirron aikana tapahtuvan salauksen, MFA:n, latausrajoitukset hallitsemattomilla laitteilla, auditointilokien säilytyksen, SIEM-hälytykset, säilytyssäännöt, toimittajien sijaintirajoitukset ja poikkeaman vakavuuden eskaloinnin.

P13 Tiedon luokittelu- ja merkintäpolitiikka asettaa perustason:

Kaiken tiedon käsittelyn, siirtämisen, käytön, säilytyksen ja hävittämisen on vastattava tiedon luokittelutasoa. Vähintään: 6.3.1.1 Julkinen: voidaan luovuttaa vapaasti; ei edellytä erityiskäsittelyä 6.3.1.2 Sisäinen: jaetaan organisaation sisällä; säilytetään turvallisissa sisäisissä järjestelmissä 6.3.1.3 Luottamuksellinen: 6.3.1.3.1 Pääsy rajataan vain valtuutetulle henkilöstölle 6.3.1.3.2 Tiedot on salattava siirron aikana ja lepotilassa 6.3.1.3.3 Tietoja saa jakaa ulkoisesti vain NDA:n tai vastaavien sopimuksellisten suojatoimien perusteella 6.3.1.4 Rajoitettu: 6.3.1.4.1 Sovelletaan korkeimpia tietoturvavaatimuksia 6.3.1.4.2 Vahvat pääsynhallintakontrollit, monivaiheinen todennus (MFA) ja auditointilokitus ovat pakollisia 6.3.1.4.3 Fyysinen ja looginen eriyttäminen toteutetaan mahdollisuuksien mukaan 6.3.1.4.4 Ulkoinen jakaminen on kielletty ilman tietoturvajohtajan hyväksyntää

Jokaisella merkinnällä on siihen liittyvä toimintatapa. Jokaisella toimintatavalla on kontrolli. Jokaisella kontrollilla on auditointinäyttö.

Käytännön esimerkki soveltamisesta

Kuvitellaan fintech-analyytikko, joka luo tiedoston Q3_2026_Customer_Churn_Analysis.xlsx. Laskentataulukko sisältää asiakastunnuksia, transaktiomääriä ja ennakoivaa asiakaspoistuman pisteytystä.

Analyytikko luokittelee sen Luottamukselliseksi, koska se sisältää asiakastietoja ja strategista analyysiä. Yhtiön tietojen suojaustyökalulla analyytikko lisää Luottamuksellinen-merkinnän. Koska merkintä on pysyvä, näkyvä ja koneluettava, kontrollit aktivoituvat automaattisesti.

Tiedosto salataan lepotilassa laitteessa ja pilvitallennuksessa. Näkyvä otsake merkitsee sen Luottamukselliseksi. Kun analyytikko yrittää synkronoida sen henkilökohtaiseen pilvitallennuspalveluun, DLP-sääntö estää toiminnon ja kirjaa yrityksen lokiin. Kun analyytikko yrittää lähettää sen sähköpostitse ulkoiseen ei-kumppaniverkkotunnukseen, sähköpostiyhdyskäytävä asettaa viestin karanteeniin ja hälyttää tietoturvavalvonnan. Jos tiedosto myöhemmin luokitellaan uudelleen Rajoitettu-tasolle, koska se sisältää sääntelyn alaisia rahoitustransaktiotietoja, ulkoinen jakaminen poistetaan käytöstä, ellei tietoturvajohtaja tai tiedon omistaja hyväksy poikkeusta.

Tämä on näyttö, jota toimitusjohtaja halusi. Se on jäljitettävissä, automatisoitu ja sidottu hallituksen hyväksymään politiikkaan. Se on myös yhdenmukainen P27 Pilvipalvelujen käyttöpolitiikan kanssa, koska pilvisiirtoja ei sallita ilman luokittelua ja rajat ylittävien siirtojen on täytettävä GDPR Chapter V:n sekä soveltuvin osin DORA Article 28:n vaatimukset.

Rakenna luokittelun ja kontrollien matriisi viikossa

Täysi ohjelma vie aikaa, mutta kohdennettu sprintti voi luoda auditointinäytön rungon ennen auditointia, asiakaskatselmointia tai sääntelyarviointia.

Päivä 1: Vahvista luokittelumalli

Aloita neljästä tasosta: Julkinen, Sisäinen, Luottamuksellinen ja Rajoitettu. Käytä P13 Tiedon luokittelu- ja merkintäpolitiikkaa perustasona. Määritä kriteerit liiketoimintavaikutuksen, oikeudellisen vaikutuksen, sopimuksellisen arkaluonteisuuden, henkilötietoriskin, palvelukriittisyyden ja taloudellisen haitan perusteella.

Päivä 2: Valitse kymmenen kriittistä tietovarallisuutta

Käytä Zenith Blueprint -tiekartan vaihetta 9. Sisällytä asiakastietokanta, tukitikettijärjestelmä, HR-alusta, identiteetintarjoaja, maksuvienti, data warehouse, objektitallennussäiliö, hallitusraportoinnin kansio, lähdekoodirepositorio ja poikkeamanäytön tietovarasto. Kirjaa omistaja, sijainti, luokitus ja GDPR-relevanssi.

Päivä 3: Kartoita käsittelysäännöt

Määritä käsittelyvaatimukset pääsylle, säilytykselle, siirrolle, seurannalle ja hävittämiselle.

Päivä 4: Määritä yksi tekninen toimeenpanopolku

Valitse yksi alusta, kuten pilvipohjainen asiakirjatietovarasto, sähköpostijärjestelmä tai objektitallennuspalvelu. Toteuta näkyvät ja koneluettavat merkinnät. Määritä yksi sääntö Luottamuksellinen-tason tiedoille ja yksi sääntö Rajoitettu-tason tiedoille. Edellytä esimerkiksi salausta Luottamuksellinen-tason ulkoisilta sähköposteilta ja estä Rajoitettu-tason tiedostojen ulkoinen jakaminen.

Päivä 5: Päivitä riskirekisteri ja SoA

Käytä Zenith Blueprint -tiekartan vaihetta 13. Lisää luokittelu- ja merkintäkontrollit soveltuvuuslausuntoon. Yhdistä ne riskeihin, kuten luvaton paljastuminen, pilven virheellinen konfiguraatio, toimittajan liiallinen altistus, tietojen säilytyksen epäonnistuminen ja poikkeamien aliraportointi.

Päivä 6: Testaa kontrolli

Luo Rajoitettu-merkinnällä varustettu testitiedosto. Yritä jakaa se ulkoisesti hallitsemattomalta laitteelta. Varmista, estääkö työkalu tapahtuman, varoittaako se siitä, kirjaako se sen lokiin tai eskaloiko se tapahtuman. Tallenna kuvakaappaukset, lokimerkinnät ja tikettinäyttö. Jos kontrolli epäonnistuu, kirjaa poikkeus ja korjaussuunnitelma.

Päivä 7: Kouluta ensimmäisen linjan käyttäjät

Koulutuksen tulee olla roolikohtaista. Kehittäjien on tiedettävä, milloin tuotantodataa ei saa käyttää testiympäristöissä. HR:n on ymmärrettävä, miksi työntekijätiedostot ovat Luottamuksellinen- tai Rajoitettu-tasoa. Myynnin on tiedettävä, miksi asiakasvientitiedostoja ei saa ladata hyväksymättömiin SaaS-työkaluihin. Johdon on ymmärrettävä, miksi hallitusmateriaalit, yritysostotiedostot ja sijoittajatiedot edellyttävät vahvempaa käsittelyä.

Tämä sprintti ei viimeistele koko ohjelmaa, mutta se luo auditointinäytön rungon: politiikan, inventaarion, merkinnät, käsittelysäännöt, teknisen toimeenpanon, riskien jäljitettävyyden ja koulutuksen.

Miten auditoijat testaavat luokittelua ja merkintää

Auditoijat testaavat luokittelua harvoin erillisenä kokonaisuutena. He seuraavat tietoa.

ISO/IEC 27001:2022 -auditoija yhdistää luokittelun ISMS:n soveltamisalaan, sidosryhmien vaatimuksiin, lakisääteisiin ja sopimusperusteisiin velvoitteisiin, riskien arviointiin ja soveltuvuuslausuntoon. Hän odottaa auditointinäyttöä ISO/IEC 27002:2022 -hallintakeinoista 5.9, 5.12, 5.13, 5.14, 5.15 ja 5.34 sekä asiaankuuluvista teknisistä kontrolleista. Tyypillinen auditointinäyttö sisältää hyväksytyt politiikat, omaisuusluettelon tallenteet, riskirekisterimerkinnät, merkityt näytteet, käsittelysäännöt, käyttöoikeuskatselmoinnit, sisäisen tarkastuksen havainnot ja korjaavat toimenpiteet.

GDPR-arvioija keskittyy henkilötietoihin. Hän kysyy, onko henkilötiedot tunnistettu, erotetaanko erityisiin henkilötietoryhmiin kuuluvat tiedot, vastaavatko säilytyssäännöt käyttötarkoitusta ja ovatko Article 32:n turvallisuustoimenpiteet asianmukaisia. Luokittelu auttaa erottamaan tavanomaisen liiketoimintatiedon henkilötiedoista, arkaluonteisista henkilötiedoista, luottamuksellisista asiakastiedoista ja sääntelyn alaisista tallenteista. Merkintä auttaa operatiivisia tiimejä välttämään tahattoman paljastumisen, liiallisen säilyttämisen ja luvattoman siirron.

NIST CSF 2.0 -arvioija tarkastelee luokittelua todennäköisesti GOVERN-, IDENTIFY- ja PROTECT-toimintojen alla. Hän voi kysyä, määrittävätkö nyky- ja tavoiteprofiilit arkaluonteisten tietojen löytämisen, toimiiko merkintöjen toimeenpano SaaS- ja pilvijärjestelmissä, käsittelevätkö toimittajat tietoja luokituksen mukaisesti ja muuttuvatko seurannan prioriteetit arkaluonteisuuden perusteella.

COBIT 2019- tai ISACA-tyylinen auditoija painottaa hallinnointitavoitteita, prosessinomistajuutta, kontrollien suunnittelua ja toiminnan tehokkuutta. Zenith Controls kartoittaa inventaariokontrollin 5.9 COBIT 2019 BAI09.01:een, BAI09.02:een ja DSS05.04:ään sekä viittaa ISACA ITAF 2204:ään ja 2301:een. Luokittelun osalta Zenith Controls kartoittaa hallintakeinon 5.12 COBIT 2019 DSS06.06:een ja APO13.01:een, kun taas merkintä kartoittuu DSS06.06:een. Auditoija kysyy, kuka omistaa prosessin, miten poikkeukset hyväksytään, seurataanko suorituskykyä ja saako johto raportointia.

DORA-painotteinen arvioija kysyy, mitkä tietovarat tukevat kriittisiä tai tärkeitä toimintoja, mitkä tiedot ovat Rajoitettu-tasoa, mitkä ICT-kolmannen osapuolen palveluntarjoajat säilyttävät tai siirtävät näitä tietoja, määrittävätkö sopimukset sijainnit ja turvallisuustoimenpiteet, kohdennetaanko testaus kriittisiin tietoihin ja luokitellaanko poikkeamat osittain tietojen menetyksen perusteella saatavuuden, aitouden, eheyden ja luottamuksellisuuden näkökulmista.

Kun vastaukset tulevat yhdestä luokitteluun perustuvasta omaisuus- ja toimittajanäyttömallista, auditoinneista tulee nopeampia, yhdenmukaisempia ja paremmin puolustettavissa olevia.

Yleiset epäonnistumismallit

Luokittelu epäonnistuu yleensä siksi, että organisaatiot käsittelevät merkintöjä tietoisuustyökaluina eivätkä kontrollisignaaleina.

Ensinnäkin ne luokittelevat asiakirjoja, mutta eivät tietokantoja, ohjelmointirajapintoja, lokeja, varmuuskopioita, vientitiedostoja tai SaaS-tallenteita. Debug-lokissa oleva arkaluonteinen tieto voi olla yhtä vahingollista kuin laskentataulukossa oleva arkaluonteinen tieto.

Toiseksi ne merkitsevät tiedon mutta eivät yhdistä merkintöjä pääsynhallintaan. Rajoitettu-merkintä avoimella pääsyllä osoittaa, että organisaatio tiesi arkaluonteisuuden mutta ei soveltanut käsittelysääntöä.

Kolmanneksi pilvimigraatiot tapahtuvat ennen luokittelua. Tiimit siirtävät tietoja uusiin SaaS-työkaluihin vahvistamatta tietojen sijaintia, toimittajaehtoja, alikäsittelijöiden pääsyä, rajat ylittäviä siirtovaatimuksia tai poisto-oikeuksia. P27 Pilvipalvelujen käyttöpolitiikka puuttuu tähän suoraan kieltämällä siirrot pilvialustoille ilman luokittelua.

Neljänneksi tietoturvapoikkeamiin reagointisuunnitelmat sivuuttavat luokittelun. Jos vakavuuskriteerit eivät sisällä tietojen arkaluonteisuutta, poikkeamatiimit käyttävät kriisin aikana aikaa sen selvittämiseen, mihin vaikutukset kohdistuivat. GDPR-loukkausanalyysi, NIS2:n poikkeamien käsittely ja DORA:n poikkeamien luokittelu hyötyvät nopeasta tietokontekstista.

Viidenneksi SoA ei selitä, miksi luokittelu- ja merkintäkontrollit ovat soveltuvia. Organisaatio on ehkä toteuttanut merkinnät, mutta SoA ei yhdistä niitä GDPR Article 32:een, NIS2 Article 21:een, DORA:n ICT-riskiin, asiakassopimuksiin tai tiettyihin riskiskenaarioihin.

Johdon raportointi: tee luokittelu näkyväksi

NIS2 ja DORA tekevät kyberturvallisuudesta johdon vastuuvelvollisuuskysymyksen. ISO/IEC 27001:2022 edellyttää myös johdon sitoutumista, politiikan yhdenmukaisuutta, resursseja, rooleja ja suorituskyvyn raportointia. Luokittelumittareiden tulee siksi sisältyä johdon katselmukseen.

Hyödyllisiä mittareita ovat:

• Niiden kriittisten tietovarojen prosenttiosuus, joille on nimetty omistaja.
• Hyväksytyn luokituksen saaneiden omaisuuserien prosenttiosuus.
• Rajoitettu-tason omaisuuserien määrä, joilta puuttuu tehostettu lokitus.
• Luottamuksellinen- tai Rajoitettu-tason tietovarastojen määrä, joissa ulkoinen jakaminen on käytössä.
• Niiden toimittajien prosenttiosuus, jotka käsittelevät Luottamuksellinen- tai Rajoitettu-tason tietoja ja joilla on päivitetyt sopimuslausekkeet.
• Luokittelupoikkeusten ja myöhässä olevien korjaavien toimenpiteiden määrä.
• DLP-poikkeamat merkinnän mukaan.
• Rajoitettu-tason omaisuuserien käyttöoikeuskatselmointien valmistumisaste.
• GDPR:n sääntelyn alaisten tietojen pilvitallennussijainnit.
• Tietoturvapoikkeamiin reagoinnin harjoitukset, joissa käytettiin luokitteluun perustuvia vakavuuskriteerejä.

Nämä mittarit tukevat ISO/IEC 27001:2022:n johdon katselmusta, NIS2:n johdon valvontaa, DORA:n hallinnointiraportointia ja asiakkaiden varmentamista. Ne tekevät luokittelusta myös johdolle ymmärrettävää. Johto voi toimia nopeammin, kun se näkee, että useilta Rajoitettu-tason tietovarastoilta puuttuu testattu palautus tai että kriittiset toimittajat käsittelevät asiakastietoja ilman vahvistettua EU-tallennusta.

Politiikasta näytöksi

Clarysecin toteutusmalli on näyttöohjattu:

1. Määritä luokittelumalli P13 Tiedon luokittelu- ja merkintäpolitiikassa tai aloita Tiedon luokittelu- ja merkintäpolitiikalla pk-yrityksille.
2. Lisää luokittelu omaisuusluetteloon P12 Omaisuudenhallintapolitiikan mukaisesti.
3. Sovella pilvirajoituksia ja tietojen sijaintivaatimuksia P27 Pilvipalvelujen käyttöpolitiikan kautta.
4. Käytä Zenith Blueprint -tiekartan vaihetta 9 tietovarojen, omistajien, sijaintien ja arkaluonteisuuden tunnistamiseen.
5. Käytä Zenith Blueprint -tiekartan vaihetta 13 riskien kartoittamiseen kontrolleihin SoA:ssa.
6. Käytä Zenith Blueprint -tiekartan vaihetta 22 ISO/IEC 27002:2022 -hallintakeinojen 5.12 ja 5.13 toteuttamiseen päivittäisessä toiminnassa.
7. Käytä Zenith Controls -opasta saman auditointinäytön kartoittamiseen GDPR:ään, NIS2:een, DORA:an, NIST CSF:ään, COBIT 2019:ään ja tukeviin standardeihin.
8. Testaa merkintöjen toimeenpano, pääsyrajoitukset, lokitus, DLP ja poikkeamien triage.
9. Raportoi luokittelun suorituskyky johdolle.
10. Katselmoi luokittelu merkittävien järjestelmä-, prosessi-, toimittaja- tai sääntelymuutosten jälkeen.

Tämä toimii, koska luokittelusta tulee yhteinen kieli liiketoiminta-arvon, lakisääteisen velvoitteen, teknisen kontrollin ja auditointinäytön välille.

Jos organisaatiosi valmistautuu ISO/IEC 27001:2022 -sertifiointiin, GDPR-varmentamiseen, NIS2-valmiuteen, DORA-asiakashuolellisuusarviointiin tai yhdistettyyn vaatimustenmukaisuusauditointiin, aloita yhdestä kysymyksestä:

Voitteko osoittaa jokaisen kriittisen tietovarallisuuden osalta, mitä se on, kuka sen omistaa, missä se sijaitsee, miten se on luokiteltu, miten se on merkitty, kuka siihen pääsee, miten sitä suojataan, kuinka kauan sitä säilytetään, mikä toimittaja siihen liittyy ja mitä tapahtuu, jos se paljastuu?

Jos vastaus on ei vielä, Clarysec voi auttaa rakentamaan auditointinäyttöketjun nopeasti ja puolustettavasti.

Käytä Tiedon luokittelu- ja merkintäpolitiikkaa pk-yrityksille, P13 Tiedon luokittelu- ja merkintäpolitiikkaa, P12 Omaisuudenhallintapolitiikkaa, P27 Pilvipalvelujen käyttöpolitiikkaa, Zenith Blueprint: auditoijan 30-vaiheista tiekarttaa ja Zenith Controls: vaatimustenmukaisuuden ristiinkartoitusopasta, jotta luokittelu muuttuu staattisesta politiikasta operatiiviseksi kontrollikerrokseksi GDPR Article 32:ta, NIS2:n kyberriskienhallintaa ja DORA:n ICT-riskienhallinnan auditointinäyttöä varten.

Paras aika luokitella tiedot oli ennen auditointipyyntöä. Seuraavaksi paras aika on ennen seuraavaa pilvimigraatiota, toimittajan käyttöönottoa, asiakaskyselyä tai poikkeamaa.