DLP vuonna 2026: ISO 27001 GDPR-asetuksen, NIS2-direktiivin ja DORA-asetuksen näkökulmasta

Kaikki alkaa laskentataulukosta.

Maanantaina klo 08.17 asiakkuuksien onnistumisesta vastaava päällikkö vie CRM-järjestelmästä 14 000 yrityskontaktia uudistuskampanjan valmistelua varten. Klo 08.24 laskentataulukko liitetään sähköpostiin. Klo 08.26 sähköposti lähetetään henkilökohtaiseen Gmail-tiliin, koska työntekijä haluaa työskennellä junamatkan aikana. Klo 08.31 sama tiedosto ladataan hyväksymättömään AI-muistiinpanopalveluun kaksoiskappaleiden “siistimistä” varten.

Mikään ei vielä näytä tietoturvaloukkaukselta. Ei ole kiristyshaittaohjelmaviestiä, haittaohjelman beacon-liikennettä, vaarantunutta ylläpitäjätiliä eikä julkista vuotoa. Tietoturvajohtajan, vaatimustenmukaisuuspäällikön ja tietosuojavastaavan kannalta olennainen kysymys on kuitenkin jo käsillä: voiko organisaatio osoittaa, että tämä tietojen liikkuminen oli sallittua, luokiteltua, lokitettua, salattua, perusteltua ja peruutettavissa?

Sama skenaario toistuu rahoituspalveluissa viikoittain. Kehittäjä yrittää ladata tiedoston Q1_Investor_Projections_DRAFT.xlsx henkilökohtaiseen pilvitallennuspalveluun, koska VPN on hidas. Myyntipäällikkö vie asiakasluettelon kuluttajakäyttöiseen yhteistyösovellukseen. Tukianalyytikko liittää asiakastietueita hyväksymättömään AI-työkaluun. Jokaisessa tapauksessa tarkoitus voi olla käytännöllisyys eikä pahantahtoisuus, mutta riski on sama. Arkaluonteiset tiedot ovat ylittäneet tai lähes ylittäneet rajan, jota organisaatio ei hallitse.

Tämä on nykyaikaisen tiedonvuodon estämisen ydinongelma. DLP ei ole enää pelkkä sähköpostiyhdyskäytävän sääntö tai päätelaiteagentti. Vuonna 2026 tehokas tiedonvuodon estäminen on hallittu, näyttöön perustuva kontrollijärjestelmä, joka kattaa SaaS-palvelut, pilvitallennuksen, päätelaitteet, mobiililaitteet, toimittajat, ohjelmointirajapinnat, kehitysympäristöt, varmuuskopioiden viennit, yhteistyövälineet ja inhimilliset oikopolut.

GDPR Article 32 edellyttää asianmukaisia teknisiä ja organisatorisia toimenpiteitä käsittelyn turvallisuuden varmistamiseksi. NIS2 Article 21 edellyttää riskiperusteisia kyberturvallisuustoimenpiteitä, mukaan lukien kyberhygienia, pääsynhallinta, omaisuudenhallinta, toimitusketjun turvallisuus, poikkeamien käsittely, salaus ja vaikuttavuuden testaus. DORA edellyttää, että rahoitusalan toimijat hallitsevat ICT-riskiä hallinnoinnin, havaitsemisen, reagoinnin, toipumisen, testauksen, kolmansien osapuolten valvonnan ja auditoitavuuden avulla. ISO/IEC 27001:2022 antaa hallintajärjestelmäperustan, jolla nämä velvoitteet muutetaan operatiivisiksi, mitattaviksi ja todennettaviksi.

Monen organisaation virhe on ostaa DLP-työkalu ennen kuin on määritelty, mitä “menetys” tarkoittaa. Clarysecin lähestymistapa alkaa tätä aiemmin: luokitellaan tiedot, määritellään sallitut siirrot, sovelletaan politiikkaa, valvotaan poikkeamia, valmistellaan reagointinäyttö ja kytketään kokonaisuus ISMS:ään.

Kuten Zenith Blueprint: An Auditor’s 30-Step Roadmap toteaa Controls in Action -vaiheen vaiheessa 19, Technological Controls I:

Tietovuodon estämisessä on kyse arkaluonteisten tietojen luvattoman tai tahattoman luovuttamisen pysäyttämisestä riippumatta siitä, tapahtuuko se sähköpostin, pilvilatausten, siirrettävien tietovälineiden tai unohtuneen tulosteen kautta. Hallintakeino 8.12 käsittelee tarvetta seurata, rajoittaa ja käsitellä kaikkia tietoja, jotka poistuvat organisaation luotetuista rajoista, riippumatta siitä, ovatko ne digitaalisia, fyysisiä vai ihmisen toiminnasta johtuvia. Zenith Blueprint

Tämä lause tiivistää DLP:n ytimen vuonna 2026: valvo, rajoita ja reagoi.

Miksi DLP on nyt hallitustason vaatimustenmukaisuuskysymys

Hallitus ei yleensä kysy, tunnistaako DLP:n säännöllinen lauseke kansallisia henkilötunnuksia. Se kysyy, pystyykö organisaatio suojaamaan asiakkaiden luottamusta, jatkamaan toimintaansa, välttämään sääntelyyn liittyvän altistumisen ja osoittamaan kohtuullisen tietoturvan, kun jokin menee pieleen.

Tässä GDPR, NIS2 ja DORA kohtaavat.

GDPR koskee laajasti automatisoitua henkilötietojen käsittelyä, mukaan lukien EU:hun sijoittautuneet rekisterinpitäjät ja käsittelijät sekä EU:n ulkopuoliset organisaatiot, jotka tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään. Se määrittelee henkilötiedot laajasti ja kattaa toiminnot, kuten keräämisen, säilyttämisen, käytön, luovuttamisen, poistamisen ja tuhoamisen. Henkilötietojen luvaton luovuttaminen tai niihin pääsy voi olla henkilötietojen tietoturvaloukkaus. GDPR Article 5 tekee myös osoitusvelvollisuudesta nimenomaisen: organisaatioille ei riitä, että ne noudattavat periaatteita, kuten tietojen minimointia, säilytyksen rajoittamista, eheyttä ja luottamuksellisuutta, vaan niiden on pystyttävä osoittamaan vaatimustenmukaisuutensa.

NIS2 laajentaa painetta tietosuojan ulkopuolelle. Se koskee monia keskeisiä ja tärkeitä toimijoita, kuten pankkialaa, rahoitusmarkkinoiden infrastruktuureja, pilvipalvelujen tarjoajia, datakeskuspalvelujen tarjoajia, hallinnoituja palveluntarjoajia, hallinnoituja tietoturvapalveluntarjoajia, verkkomarkkinapaikkoja, hakukoneita ja sosiaalisen verkostoitumisen alustoja. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, tietojärjestelmien tietoturvapolitiikat, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen kehittäminen, vaikuttavuuden testaus, kyberhygienia, koulutus, kryptografia, pääsynhallinta, omaisuudenhallinta ja todennus.

DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se toimii rahoitusalan erillisenä ICT-häiriönsietokyvyn sääntökirjana. Soveltamisalaan kuuluville rahoitusalan toimijoille sitä käsitellään alakohtaisena unionin säädöksenä niiltä osin kuin se limittyy NIS2:n kanssa. DORA tuo DLP:n osaksi ICT-riskien hallintaa, poikkeamien luokittelua, saatavuuteen, aitouteen, eheyteen tai luottamuksellisuuteen vaikuttavaa tietojen menetystä, digitaalisen toiminnan häiriönsietokyvyn testausta, ICT-kolmansien osapuolten hallintaa ja sopimuksellisia kontrolleja.

Vuoden 2026 DLP-kysymys ei ole “Omistammeko työkalun?” Se on:

1. Tiedämmekö, mitkä tiedot ovat arkaluonteisia?
2. Tiedämmekö, missä niitä säilytetään, käsitellään ja siirretään?
3. Onko sallitut ja kielletyt siirtoreitit määritelty?
4. Onko käyttäjät koulutettu ja teknisesti rajoitettu?
5. Onko pilvi- ja SaaS-reitit hallittu?
6. Riittävätkö lokit tutkintaan?
7. Luokitellaanko hälytykset ja poikkeamat nopeasti?
8. Sitovatko sopimukset toimittajia ja ulkoistettuja ICT-palveluja?
9. Voimmeko osoittaa, että kontrollit toimivat?

ISO/IEC 27001:2022 soveltuu hyvin näihin kysymyksiin vastaamiseen, koska se edellyttää toimintaympäristön määrittämistä, sidosryhmävaatimusten tunnistamista, riskien arviointia, riskien käsittelyä, mitattavia tavoitteita, operatiivista kontrollia, dokumentoitua näyttöä, toimittajakontrolleja, sisäistä auditointia, johdon katselmointia ja jatkuvaa parantamista. Se ei ole DLP-standardi, mutta se muuttaa DLP:n erillisestä teknologiakonfiguraatiosta hallituksi hallintajärjestelmäprosessiksi.

Tehokkaan DLP:n taustalla oleva ISO 27001 -kontrolliketju

Uskottavaa DLP-ohjelmaa ei rakenneta yhden kontrollin varaan. Se rakennetaan ketjuksi.

Clarysecin Zenith Controls: The Cross-Compliance Guide kartoittaa ISO/IEC 27002:2022 -kontrollin 8.12, tietovuodon estäminen, ennaltaehkäiseväksi ja havaitsevaksi kontrolliksi, joka keskittyy luottamuksellisuuteen, on linjassa Protect- ja Detect-kyberturvallisuuskäsitteiden kanssa ja jossa tietojen suojaus on operatiivinen kyvykkyys ja suojaus/puolustus tietoturva-alue. Zenith Controls

Tällä on merkitystä, koska auditoijat odottavat sekä estoa että näkyvyyttä. Ennaltaehkäisevä DLP-sääntö ilman hälytysten katselmointia on puutteellinen. Pelkkään lokitukseen perustuva lähestymistapa ilman korkean riskin siirtojen rajoittamista on myös heikko.

Sama opas kartoittaa ISO/IEC 27002:2022 -kontrollin 5.12, tiedon luokittelu, ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta ja on linjassa Identify-toiminnon kanssa. Kontrolli 5.14, tiedon siirto, kartoitetaan ennaltaehkäiseväksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta ja on linjassa Protect-toiminnon, omaisuudenhallinnan ja tietojen suojauksen kanssa.

Käytännössä DLP-kontrolliketju näyttää tältä:

Zenith Blueprint, vaihe 22, selittää omaisuusluettelon, luokittelun ja DLP:n välisen riippuvuuden:

Katselmoi nykyinen omaisuusluettelo (5.9) varmistaaksesi, että se sisältää sekä fyysiset että loogiset omaisuuserät, omistajat ja luokitukset. Kytke tämä luettelo luokittelumalliin (5.12) ja varmista, että arkaluonteiset omaisuuserät on merkitty ja suojattu asianmukaisesti. Määritä tarvittaessa säilytys, varmuuskopiointi tai eristäminen luokituksen perusteella.

Tästä syystä Clarysec aloittaa DLP-toimeksiannon harvoin sääntöjen hienosäädöllä. Aloitamme yhteensovittamalla omaisuuserät, omistajat, tietotyypit, luokitusmerkinnät, siirtoreitit ja näyttötallenteet. Jos organisaatio ei pysty sanomaan, mitkä tietoaineistot ovat luottamuksellisia, sääntelyn alaisia, asiakkaan omistamia, maksuihin liittyviä tai toimintakriittisiä, DLP-työkalu voi vain arvata.

Nykyaikaisen DLP-ohjelman kolme pilaria

Nykyaikainen DLP-ohjelma perustuu kolmeen toisiaan vahvistavaan pilariin: tunne data, hallitse virtausta ja suojaa raja. Nämä pilarit tekevät ISO/IEC 27001:2022:sta käytännöllisen GDPR-, NIS2- ja DORA-vaatimustenmukaisuuden kannalta.

Pilari 1: Tunne data luokittelun ja merkintöjen avulla

Et voi suojata sitä, mitä et ymmärrä. ISO/IEC 27002:2022 -kontrollit 5.12 ja 5.13 edellyttävät, että organisaatiot luokittelevat tiedon ja merkitsevät sen arkaluonteisuuden ja käsittelytarpeiden mukaan. Tämä ei ole paperiharjoitus. Se on automatisoidun soveltamisen perusta.

Pk-yrityksille tarkoitettu Tiedon luokittelu- ja merkintäpolitiikka toteaa:

Luottamuksellinen: Edellyttää salausta siirrettäessä ja lepotilassa, rajoitettua pääsyä, nimenomaista hyväksyntää jakamiselle ja turvallista tuhoamista hävittämisen yhteydessä. Data Classification and Labeling Policy - SME

Tämä lainaus osiosta “Politiikan toteutusvaatimukset”, kohta 6.3.3, antaa DLP-ohjelmalle neljä sovellettavaa ehtoa: salaus, rajoitettu pääsy, jakamisen hyväksyntä ja turvallinen hävittäminen.

Yritysympäristöissä Tiedon luokittelu- ja merkintäpolitiikka on vielä suorempi. Osiosta “Politiikan toteutusvaatimukset”, kohta 6.2.6.2:

Estä virheellisesti merkittyjen arkaluonteisten tietojen siirto (esim. ulkoinen sähköposti) Data Classification and Labeling Policy

Ja osiosta “Soveltaminen ja vaatimustenmukaisuus”, kohta 8.3.2:

Automatisoitu luokittelun validointi tiedonvuodon estämisen (DLP) ja tiedon löytämisen työkalujen avulla

Nämä kohdat muuttavat luokittelun kontrolliksi. Luottamukselliseksi merkitty tiedosto voi käynnistää salauksen, estää ulkoisen siirron, edellyttää hyväksyntää tai luoda tietoturvahälytyksen. DLP:stä tulee tällöin politiikan toimeenpanokerros, jonka käyttäjät, järjestelmät ja auditoijat ymmärtävät.

Pilari 2: Hallitse virtausta turvallisen tiedonsiirron avulla

Kun data on luokiteltu, organisaation on hallittava, miten se liikkuu. ISO/IEC 27002:2022 -kontrolli 5.14, tiedon siirto, jää usein liian vähälle huomiolle, mutta juuri siinä moni DLP-epäonnistuminen alkaa.

Zenith Blueprint kuvaa kontrollin 5.14 tarpeena hallita tietovirtoja niin, että siirto on turvallista, tarkoituksellista ja luokituksen sekä liiketoimintatarkoituksen mukaista. Tämä koskee sähköpostia, turvallista tiedostojen jakamista, ohjelmointirajapintoja, SaaS-integraatioita, siirrettäviä tallennusvälineitä, tulostettuja raportteja ja toimittajaportaaleja.

Etätyö tekee tästä erityisen tärkeää. Etätyöpolitiikka, osio “Politiikan toteutusvaatimukset”, kohta 6.3.1.3, edellyttää työntekijöiltä seuraavaa:

Käytä vain hyväksyttyjä tiedostonjakoratkaisuja (esim. M365, Google Workspace, jossa on tiedonvuodon estämisen (DLP) kontrollit) Remote Work Policy

Mobiililaitteiden ja BYOD-käytön osalta Mobiililaitteiden ja BYOD-käytön politiikka, osio “Politiikan toteutusvaatimukset”, kohta 6.6.4, antaa konkreettisen päätelaitetason toimeenpanovaatimuksen:

Tiedonvuodon estämisen (DLP) politiikkojen tulee estää luvattomat lataukset, näyttökuvat, leikepöydän käyttö tai tietojen jakaminen hallituista sovelluksista henkilökohtaisiin alueisiin. Mobile device and byod policy

Tällä on merkitystä, koska data ei poistu vain sähköpostin kautta. Se poistuu näyttökuvien, leikepöydän synkronoinnin, hallitsemattomien selainprofiilien, henkilökohtaisten levyjen, mobiilijakamisen, yhteistyöliitännäisten ja AI-työkalujen kautta.

Pilvihallinnointi on yhtä tärkeää. Pk-yritysten Pilvipalvelujen käyttöpolitiikka-sme, osio “Hallinnointivaatimukset”, kohta 5.5:

Varjo-IT, joka määritellään hyväksymättömien pilvityökalujen käytöksi, on käsiteltävä politiikan rikkomuksena, ja toimitusjohtajan sekä IT-palveluntarjoajan on katselmoitava se riskin ja vaadittavien korjaavien toimenpiteiden määrittämiseksi. Cloud Usage Policy-sme - SME

Yritysorganisaatioille Pilvipalvelujen käyttöpolitiikka, osio “Hallinnointivaatimukset”, kohta 5.5, nostaa valvontavaatimusta:

Tietoturvatiimin tulee säännöllisesti arvioida verkkoliikennettä, DNS-toimintaa ja lokeja luvattoman pilvikäytön (varjo-IT) havaitsemiseksi. Havaitut rikkomukset on tutkittava viipymättä. Cloud Usage Policy

Varjo-IT ei ole vain IT-haitta. GDPR:n nojalla siitä voi tulla lainvastainen luovutus tai hallitsematon käsittely. NIS2:n näkökulmasta se on kyberhygienian ja toimitusketjun heikkous. DORA:ssa siitä voi tulla ICT-kolmannen osapuolen riski ja poikkeaman luokittelukysymys.

Pilari 3: Suojaa raja DLP-teknologialla, politiikalla ja tietoisuudella

ISO/IEC 27002:2022 -kontrolli 8.12, tietovuodon estäminen, on kontrolli, jonka useimmat yhdistävät DLP:hen. Kypsässä ohjelmassa se on kuitenkin viimeinen puolustuslinja, ei ensimmäinen.

Zenith Blueprint selittää, että DLP edellyttää kolmikerroksista lähestymistapaa: teknologiaa, politiikkaa ja tietoisuutta. Teknologiaan kuuluvat päätelaitteiden DLP, sähköpostin tietoturva, sisällöntarkastus, pilvipääsyn suojaus, SaaS-kontrollit, selainkontrollit, verkon ulosmenoliikenteen suodatus ja hälytysten reititys. Politiikka määrittää, mitä työkalut toteuttavat. Tietoisuus varmistaa, että työntekijät ymmärtävät, miksi henkilökohtainen sähköposti, kuluttajapilvitallennus ja hyväksymättömät AI-työkalut eivät ole hyväksyttäviä käsittelytapoja sääntelyn alaisille tai luottamuksellisille tiedoille.

Reagointiosa on yhtä tärkeä kuin ennaltaehkäisy. Zenith Blueprint, vaihe 19, toteaa:

DLP ei kuitenkaan ole pelkkää ennaltaehkäisyä, vaan myös reagointia. Jos mahdollinen vuoto havaitaan:

✓ Hälytykset tulee luokitella ja priorisoida nopeasti, ✓ Lokituksen tulee tukea forensista analyysiä, ✓ Tietoturvapoikkeamiin reagointisuunnitelma on käynnistettävä viipymättä.

DLP-ohjelma, joka estää tapahtumia mutta ei luokittele, tutki eikä opi niistä, ei ole auditointivalmis. Se on vain osittain käyttöönotettu.

Laskentataulukkovuodosta auditointivalmiiseen reagointiin

Palataan maanantaiaamun laskentataulukkoon.

Heikossa ohjelmassa organisaatio havaitsee latauksen kolme viikkoa myöhemmin tietosuojakatselmoinnin aikana. Kukaan ei tiedä, kuka hyväksyi viennin, oliko data henkilötietoja, sisältyikö siihen erityisiin henkilötietoryhmiin kuuluvaa dataa, säilyttikö AI-työkalu tiedoston tai onko asiakkaille ilmoitettava.

Clarysecin suunnittelemassa ohjelmassa tapahtumaketju näyttää erilaiselta.

Ensinnäkin CRM-vienti merkitään luottamukselliseksi, koska se sisältää henkilötietoja ja asiakkaan kaupallisia tietoja. Toiseksi vientitapahtuma kirjataan lokiin. Kolmanneksi sähköpostiyhdyskäytävä havaitsee luottamuksellisen liitteen, joka on menossa henkilökohtaiseen sähköpostiverkkotunnukseen, ja estää sen, ellei hyväksyttyä poikkeusta ole. Neljänneksi yritys ladata tiedosto hyväksymättömään pilvipalveluun käynnistää pilvikäyttöhälytyksen. Viidenneksi hälytys luokitellaan ja priorisoidaan poikkeamiin reagoinnin menettelyn mukaisesti. Kuudenneksi tietoturvatiimi määrittää, tapahtuiko todellinen luovutus, oliko data salattu, käsittelikö tai säilyttikö palveluntarjoaja sitä, täyttyvätkö GDPR:n tietoturvaloukkauksen kriteerit ja soveltuvatko NIS2:n tai DORA:n poikkeamakynnykset.

Pk-yritysten Lokitus- ja valvontapolitiikka, osio “Hallinnointivaatimukset”, kohta 5.4.3, kertoo tiimille täsmällisesti, minkä tulee olla näkyvissä:

Käyttölokit: tiedostojen käyttö (erityisesti arkaluonteiset tai henkilötiedot), käyttöoikeusmuutokset, jaettujen resurssien käyttö Logging and Monitoring Policy - SME

Tämä kohta on pieni mutta ratkaiseva. Jos tiedostojen käyttöä, käyttöoikeusmuutoksia ja jaettujen resurssien käyttöä ei lokiteta, DLP-tutkinnasta tulee arvailua.

NIS2 Article 23:n mukaan merkittävät poikkeamat edellyttävät vaiheittaista raportointia: varhaisvaroitus 24 tunnin kuluessa siitä, kun poikkeamasta on tullut tieto, poikkeamailmoitus 72 tunnin kuluessa ja loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta. DORA:n Articles 17 to 19 edellyttävät, että rahoitusalan toimijat havaitsevat, hallitsevat, luokittelevat, kirjaavat, eskaloivat ja raportoivat merkittävät ICT:hen liittyvät poikkeamat. Luokittelu sisältää saatavuuteen, aitouteen, eheyteen tai luottamuksellisuuteen vaikuttavan tietojen menetyksen sekä vaikutuksen kohteena olevat asiakkaat, keston, maantieteellisen laajuuden, kriittisyyden ja taloudellisen vaikutuksen. GDPR:n mukaan henkilötietojen luvaton luovuttaminen voi edellyttää tietoturvaloukkauksen arviointia ja kynnysten täyttyessä ilmoittamista.

DLP-hälytys ei siis ole pelkkä tietoturvatapahtuma. Siitä voi tulla tietosuojaloukkauksen arviointi, NIS2-poikkeamatyönkulku, DORA:n ICT-poikkeaman luokittelu, asiakasilmoituksen käynnistin ja auditointinäyttöpaketti.

DLP-kontrollit GDPR Article 32:ta varten

GDPR Article 32 muunnetaan usein toimenpideluetteloksi: salaus, luottamuksellisuus, eheys, saatavuus, häiriönsietokyky, testaus ja palauttaminen. DLP:n kannalta avain on elinkaarisuojaus.

Henkilötiedot liikkuvat keräämisen, säilyttämisen, käytön, siirron, luovutuksen, säilytysajan ja poistamisen läpi. GDPR Article 5 edellyttää tietojen minimointia, käyttötarkoitussidonnaisuutta, säilytyksen rajoittamista, eheyttä, luottamuksellisuutta ja osoitusvelvollisuutta. GDPR Article 6 edellyttää oikeusperustetta ja käyttötarkoituksen yhteensopivuutta. GDPR Article 9 vaatii tiukempia suojatoimia erityisiin henkilötietoryhmiin kuuluville henkilötiedoille.

DLP tukee näitä velvoitteita, kun se on kytketty tiedon luokitteluun, lainmukaisen käsittelyn tallenteisiin ja hyväksyttyihin siirtoreitteihin.

Clarysecin Tietojen peittämisen ja pseudonymisoinnin politiikka-sme, osio “Tarkoitus”, kohta 1.2, tukee tätä elinkaarilähestymistapaa:

Nämä tekniikat ovat pakollisia, kun tuotantodataa ei tarvita, mukaan lukien kehitys-, analytiikka- ja kolmannen osapuolen palveluskenaariot, jotta altistumisen, väärinkäytön tai tietoturvaloukkauksen riskiä voidaan vähentää. Data Masking and Pseudonymization Policy-sme - SME

Tämä on käytännöllinen GDPR Article 32 -kontrolli. Jos kehittäjät, analyytikot tai toimittajat eivät tarvitse tuotantohenkilötietoja, DLP:n ei pitäisi olla ainoa este. Maskaus ja pseudonymisointi pienentävät vaikutusalaa ennen kuin data edes liikkuu.

Vahvan tietosuojaan sovitetun DLP-matriisin tulee kartoittaa henkilötietotyypit luokitusmerkintöihin, oikeusperusteeseen, hyväksyttyihin järjestelmiin, hyväksyttyihin vientimenetelmiin, salausvaatimuksiin, DLP-sääntöihin, säilytyssääntöihin ja poikkeamakäynnistimiin. Matriisista tulee silta tietosuojan hallinnointikehyksen ja tietoturvaoperaatioiden välillä.

NIS2:n kyberhygienia ja DLP tietosuojatiimin ulkopuolella

NIS2 muuttaa DLP-keskustelua, koska se kehystää vuodot osaksi kyberhygieniaa ja häiriönsietokykyä, ei pelkästään tietosuojaa.

Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden johtoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat toteutusta ja saavat kyberturvallisuuskoulutusta. Article 21 edellyttää asianmukaisia ja oikeasuhteisia toimenpiteitä politiikoissa, poikkeamien käsittelyssä, jatkuvuudessa, toimitusketjussa, turvallisessa kehityksessä, vaikuttavuuden testauksessa, kyberhygieniassa, koulutuksessa, kryptografiassa, HR-turvallisuudessa, pääsynhallinnassa ja omaisuudenhallinnassa. Article 25 kannustaa käyttämään asiaankuuluvia eurooppalaisia ja kansainvälisiä standardeja ja teknisiä eritelmiä.

DLP tukee suoraan näitä osa-alueita:

Verkkoturvallisuuspolitiikka-sme, osio “Tavoitteet”, kohta 3.4, tekee tietojen luvattoman siirron estämistavoitteesta nimenomaisen:

Estä haittaohjelmien leviäminen ja tietojen luvaton siirto verkkokanavien kautta Network Security Policy-sme - SME

NIS2:n kannalta tällainen tavoite antaa auditoijille suoran testipolun: näytä lähtevän liikenteen suodatus, DNS-valvonta, välityspalvelimen lokit, päätelaitehälytykset, estetyt latausyritykset ja tutkintatiketit.

Zenith Blueprint, vaihe 23, lisää pilvikohtaisen toimenpiteen, joka on nyt välttämätön NIS2:n piiriin kuuluville digitaalisille ja ICT-palveluntarjoajille:

Luettele kaikki tällä hetkellä käytössä olevat pilvipalvelut (5.23), mukaan lukien tunnettu varjo-IT. Tunnista, kuka ne hyväksyi ja suoritettiinko huolellisuus. Laadi kevyt arviointitarkistuslista, joka kattaa tietojen sijainnin, käyttöoikeusmallin, lokituksen ja salauksen. Varmista tulevien palvelujen osalta, että tarkistuslista integroidaan hankinta- tai IT-käyttöönottoprosessiin.

Moni organisaatio epäonnistuu tässä. Niillä on ISMS:n soveltamisala ja toimittajarekisteri, mutta ei todellista luetteloa SaaS-työkaluista, joihin työntekijät siirtävät sääntelyn alaista tai asiakasdataa. DLP ilman pilvipalvelujen löytämistä on sokea.

DORA:n ICT-riski: DLP rahoitusalan toimijoille ja palveluntarjoajille

Rahoitusalan toimijoilla DLP:n on sovittava DORA-asetuksen ICT-riskien hallinnan viitekehykseen.

DORA Article 5 edellyttää sisäistä hallinnointi- ja kontrollikehystä ICT-riskien hallintaan. Johtoelin vastaa edelleen ICT-riskistä, politiikoista, jotka säilyttävät tietojen saatavuuden, aitouden, eheyden ja luottamuksellisuuden, selkeistä ICT-rooleista, digitaalisen toiminnan häiriönsietokyvyn strategiasta, ICT-riskinsietokyvystä, jatkuvuus- ja reagointi-/toipumissuunnitelmista, auditointisuunnitelmista, resursseista, kolmansia osapuolia koskevasta politiikasta ja raportointikanavista.

Article 6 edellyttää dokumentoitua ICT-riskien hallinnan viitekehystä, joka kattaa strategiat, politiikat, menettelyt, ICT-protokollat ja työkalut tietojen ja ICT-omaisuuserien suojaamiseksi. Article 9 käsittelee suojausta ja ennaltaehkäisyä. Articles 11 to 14 lisäävät jatkuvuuden, reagoinnin, toipumisen, varmuuskopioinnin, palauttamisen, tietojen eheystarkastukset, opit, tietoisuuskoulutuksen ja kriisiviestinnän.

DLP sopii tähän viitekehykseen suojaus-, havaitsemis-, reagointi- ja testauskyvykkyytenä.

DORA tekee myös kolmannen osapuolen riskistä väistämättömän. Articles 28 to 30 edellyttävät ICT-kolmansien osapuolten riskienhallintaa, ICT-palvelusopimusten rekistereitä, sopimusta edeltävää huolellisuutta, sopimusvaatimuksia, auditointi- ja tarkastusoikeuksia, päättämisoikeuksia, exit-strategioita, palvelukuvauksia, tietojen käsittely- ja säilytyspaikkoja, tietojen käyttöä, palautusta ja palauttamista asiakkaalle, poikkeama-avustusta, viranomaisyhteistyötä, turvatoimia ja alihankintaehtoja.

Fintech-yrityksessä tai pankissa DLP ei voi päättyä Microsoft 365:n tai Google Workspacen rajalle. Sen on katettava maksunvälittäjät, identiteetin varmennuspalveluntarjoajat, CRM-alustat, tietovarastot, pilvi-infrastruktuuri, ulkoistetut tukipalvelut, hallinnoidut palveluntarjoajat ja kriittiset SaaS-integraatiot.

Tämä on erityisen tärkeää silloin, kun DORA toimii alakohtaisena unionin säädöksenä päällekkäisille NIS2-velvoitteille. Kontrollien on silti oltava olemassa. Raportointi- ja valvontareitti voi poiketa.

90 minuutin DLP-sääntösprintti

Clarysec käyttää asiakkaiden kanssa käytännön sprinttiä, kun tarvitaan nopeaa etenemistä ilman väitettä, että täysi DLP-ohjelma voidaan rakentaa yhdessä kokouksessa. Tavoitteena on toteuttaa yksi korkean arvon DLP-kontrolli politiikasta näyttöön.

Vaihe 1: Valitse yksi tietotyyppi ja yksi siirtoreitti

Valitse “CRM:stä viedyt asiakkaiden henkilötiedot, jotka lähetetään ulkoisesti sähköpostilla”. Älä aloita kaikista tietovarastoista, maista ja tietotyypeistä.

Vaihe 2: Vahvista luokitus ja merkintä

Käytä luokittelupolitiikkaa vahvistaaksesi, että vienti on luottamuksellinen. Pk-yrityksessä kohta 6.3.3 edellyttää salausta, rajoitettua pääsyä, nimenomaista hyväksyntää jakamiseen ja turvallista hävittämistä. Yritysympäristössä Tiedon luokittelu- ja merkintäpolitiikka tukee virheellisesti merkittyjen arkaluonteisten tietojen siirron estämistä ja automatisoitua validointia DLP- ja tiedon löytämisen työkaluilla.

Vaihe 3: Määritä sallittu siirtomalli

Sallittu: CRM-vienti lähetetään hyväksyttyyn asiakasverkkotunnukseen salatulla sähköpostilla tai hyväksytyllä turvallisella tiedostojenjakoalustalla liiketoimintaperusteen kanssa.

Ei sallittu: henkilökohtainen sähköposti, julkiset tiedostonjakolinkit, hyväksymättömät AI-työkalut ja hallitsemattomat pilvitallennuspalvelut.

Tämä on linjassa Zenith Blueprint -oppaan vaiheen 22 kanssa, jossa todetaan:

Jos “luottamuksellista” tietoa ei saa viedä yrityksen ulkopuolelle ilman salausta, sähköpostijärjestelmien on toteutettava salauspolitiikat tai estettävä ulkoinen siirto.

Vaihe 4: Määritä DLP-vähimmäissääntö

Määritä sähköposti- tai yhteistyöalusta havaitsemaan luottamuksellinen merkintä, henkilötietomalli tai vientitiedoston nimeämiskäytäntö. Aloita valvontatilalla, jos vääriä positiivisia havaintoja odotetaan, ja siirry sen jälkeen estoon henkilökohtaisten verkkotunnusten ja hyväksymättömien vastaanottajien osalta.

Vaihe 5: Ota lokitus ja hälytysten reititys käyttöön

Varmista, että lokit tallentavat tiedostojen käytön, käyttöoikeusmuutokset ja jaettujen resurssien käytön, kuten Logging and Monitoring Policy - SME edellyttää. Reititä hälytykset tikettijonoon siten, että mukana ovat vakavuus, tietotyyppi, lähettäjä, vastaanottaja, tiedostonimi, toteutettu toimi ja katselmoija.

Vaihe 6: Testaa kolme skenaariota

Testaa hyväksytty salattu siirto asiakkaalle, estetty henkilökohtaiseen sähköpostiin tehty siirto ja pelkkään hälytykseen jäävä latausyritys hyväksymättömään pilviverkkotunnukseen.

Vaihe 7: Säilytä näyttö

Tallenna politiikkakohdan viite, DLP-säännön kuvakaappaus, testitulokset, hälytystiketti, katselmoijan päätös ja johdon hyväksyntä. Lisää kontrolli riskienkäsittelysuunnitelmaan ja soveltuvuuslausuntoon.

ISO/IEC 27001:2022 -näkökulmasta tämä harjoitus yhdistää Clause 6.1.2 riskien arvioinnin, Clause 6.1.3 riskien käsittelyn, Clause 8 operatiivisen suunnittelun ja kontrollin, Annex A:n tiedonsiirron, tietovuodon estämisen, lokituksen, valvonnan, toimittaja- ja pilvikontrollit sekä Clause 9:n suorituskyvyn arvioinnin.

Monivaade-kartoitus: yksi DLP-ohjelma, monta velvoitetta

Clarysecin lähestymistavan vahvuus on, että se välttää erillisten kontrollipinojen rakentamisen GDPR:lle, NIS2:lle, DORA:lle, NIST:lle ja COBIT:lle. Yksi hyvin suunniteltu DLP-ohjelma voi täyttää useita odotuksia, jos näyttö on jäsennelty oikein.

NIST CSF 2.0 on hyödyllinen viestintäkerros. Sen GOVERN-toiminto tukee oikeudellisten, sääntelyyn liittyvien ja sopimusperusteisten vaatimusten seurantaa, riskinottohalukkuutta, politiikan soveltamista, rooleja ja valvontaa. Sen Profiles-menetelmä auttaa organisaatioita rajaamaan nykyisen ja tavoitetilan, dokumentoimaan puutteet ja toteuttamaan toimintasuunnitelman. Sen RESPOND- ja RECOVER-toiminnot tukevat DLP-poikkeamien rajaamista, juurisyyanalyysiä, näytön säilyttämistä ja palauttamista.

COBIT 2019 lisää hallinnointinäkökulman. COBIT-suuntautunut auditoija kysyy, ovatko DLP-tavoitteet linjassa yrityksen tavoitteiden kanssa, onko omistajuus selkeä, onko suorituskykyindikaattoreita, onko riskinottohalukkuus määritetty ja saako johto merkityksellistä raportointia.

Miten auditoijat testaavat DLP-ohjelmaasi

DLP-auditoinnit koskevat harvoin yhtä kuvakaappausta. Erilaiset auditointitaustat tuottavat erilaisia näyttöodotuksia.

Vahva DLP-auditointipaketti sisältää soveltamisalan ja riskikuvauksen, luokittelumallin, hyväksytyt siirtomenetelmät, DLP-säännöt, poikkeushyväksynnät, lokitussuunnittelun, hälytysten luokittelu- ja priorisointimenettelyn, poikkeamien raportointipäätöspuun, toimittaja- ja pilvi-inventaarion, testitulokset ja korjaavien toimenpiteiden tallenteet.

Yleisimmät DLP-epäonnistumiset vuonna 2026

Yleisimmät DLP-epäonnistumiset ovat operatiivisia, eivät eksoottisia.

Ensinnäkin luokittelu on vapaaehtoista tai epäjohdonmukaista. Merkinnät ovat olemassa politiikassa, mutta käyttäjät eivät sovella niitä, järjestelmät eivät toteuta niitä ja tietovarastot sisältävät vuosien ajalta merkitsemättömiä arkaluonteisia tiedostoja.

Toiseksi DLP otetaan käyttöön pysyvästi pelkässä hälytystilassa. Pelkkä hälytystila on hyödyllinen hienosäädön aikana, mutta korkean riskin henkilökohtaiseen sähköpostiin tehty luottamuksellisten asiakastietojen siirto tulisi lopulta estää, ellei hyväksyttyä poikkeusta ole.

Kolmanneksi varjo-IT:tä käsitellään IT-haittana eikä tietosuojariskinä. Pilvipalvelujen käyttöpolitiikka ja Cloud Usage Policy-sme on suunniteltu tekemään hyväksymättömistä pilvityökaluista näkyviä, katselmoitavia ja korjattavia.

Neljänneksi lokit eivät riitä tutkintaan. Jos tietoturvatiimi ei voi rekonstruoida, kuka käytti, jakoi, latasi, siirsi tai muutti käyttöoikeuksia, organisaatio ei voi luotettavasti arvioida GDPR:n, NIS2:n tai DORA:n raportointivelvoitteita.

Viidenneksi toimittajat ovat DLP-mallin ulkopuolella. DORA Articles 28 to 30 tekee tästä erityisen vaarallista rahoitusalan toimijoille, mutta ongelma koskee kaikkia toimialoja. Sopimusten tulee määrittää tietojen sijainnit, pääsy, palautus, tietojen palauttaminen asiakkaalle, poikkeama-avustus, turvatoimet, alihankinta ja auditointioikeudet.

Kuudenneksi tietoturvapoikkeamiin reagointi ei sisällä DLP-skenaarioita. Väärään osoitteeseen lähetetyllä sähköpostilla, luvattomalla SaaS-latauksella tai CRM:n massaviennillä tulee olla pelikirja, vakavuuskriteerit ja ilmoituspäätöspolku.

Lopuksi organisaatiot unohtavat fyysiset ja inhimilliset kanavat. Zenith Blueprint muistuttaa, että DLP sisältää puhtaan pöydän käytännöt, turvallisen silppuamisen, lukitut tulostusjonot, tulostimien auditointilokit ja työntekijöiden tietoisuuden. DLP-ohjelma, joka sivuuttaa paperin, näyttökuvat ja keskustelut, on puutteellinen.

Rakenna DLP-ohjelma, johon auditoijat voivat luottaa

Jos DLP-ohjelmasi on tällä hetkellä työkalukonfiguraatio, vuosi 2026 on aika muuttaa se hallituksi, näyttöön perustuvaksi kontrollijärjestelmäksi.

Aloita kolmella käytännön toimenpiteellä:

1. Valitse kolme tärkeintä arkaluonteista tietotyyppiä, kuten asiakkaiden henkilötiedot, maksutiedot ja lähdekoodi.
2. Kartoita, missä ne liikkuvat, mukaan lukien sähköposti, SaaS, pilvitallennus, päätelaitteet, ohjelmointirajapinnat, toimittajat ja kehitysympäristöt.
3. Rakenna yksi sovellettava DLP-sääntö kutakin tietotyyppiä kohti ja kytke se politiikkaan, lokitukseen, tietoturvapoikkeamiin reagointiin ja näytön säilyttämiseen.

Clarysec voi auttaa nopeuttamaan tätä Zenith Blueprint: An Auditor’s 30-Step Roadmap -oppaan Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide -oppaan Zenith Controls sekä muokattavien politiikkojen avulla, kuten Tiedon luokittelu- ja merkintäpolitiikka Data Classification and Labeling Policy, Etätyöpolitiikka Remote Work Policy, Pilvipalvelujen käyttöpolitiikka Cloud Usage Policy, Lokitus- ja valvontapolitiikka-sme Logging and Monitoring Policy - SME ja Mobiililaitteiden ja BYOD-käytön politiikka Mobile device and byod policy.

Tavoitteena ei ole estää jokaista tiedostoa liikkumasta. Tavoitteena on tehdä turvallisesta liikkumisesta oletus, riskialttiista liikkumisesta näkyvää, kielletystä liikkumisesta estettyä ja jokaisesta poikkeuksesta vastuutettu.

Lataa Clarysecin työkalupaketit, katselmoi DLP-näyttöpakettisi ja varaa valmiusarviointi nähdäksesi, kestävätkö nykyiset kontrollisi GDPR Article 32:n tarkastelun, NIS2:n kyberhygieniaodotukset ja DORA:n ICT-riskitarkastelun.