Teknisten ja organisatoristen turvatoimien kuvaus kertoo, miten henkilötietojen käsittely suojataan ja millä havainnoilla suojausten toimivuus osoitetaan. Hyödyllinen malli yhdistää riskin, toimenpiteen, vastuun ja todentamisen. Pelkkä rastitettu luettelo salauksesta, varmuuskopioista ja henkilöstön koulutuksesta jättää avoimeksi, missä suojaukset ovat käytössä.
Tässä oppaassa on täytetty kuvaus kuvitteellisen Hankevirta Oy:n asiakasprojektien hallinnasta. Esimerkissä erotetaan jo todetut toimet, vielä avoimet puutteet ja palveluntarjoajan vastuulla olevat osat. Mallia voi käyttää oman asiakirjan rakenteena, kun jokainen väite sovitetaan todelliseen käsittelyyn.
Mitä GDPR:n 32 artikla edellyttää?
Rekisterinpitäjän ja henkilötietojen käsittelijän on toteutettava riskiä vastaavat tekniset ja organisatoriset toimenpiteet. Arviossa huomioidaan uusin tekniikka, toteuttamiskustannukset, käsittelyn luonne, laajuus, asiayhteys ja tarkoitukset sekä ihmisten oikeuksiin ja vapauksiin kohdistuvien riskien todennäköisyys ja vakavuus. Asetuksen esimerkkeihin kuuluvat salaus ja pseudonymisointi, jatkuva luottamuksellisuus, eheys, käytettävyys ja vikasietoisuus, palauttamiskyky sekä säännöllinen toimivuuden arviointi. GDPR:n 32 artikla.
Artikla ei määrää yhtä kaikille sopivaa turvatoimiluetteloa eikä yleistä vuosittaista tarkistuspäivää. Myöskään erillinen ”TOM-liite” tällä nimellä ei ole jokaisen käsittelysopimuksen pakollinen muoto. Sopimuksen pitää kuitenkin sisältää 28 artiklan edellyttämät sitoumukset, mukaan lukien tarvittavat 32 artiklan toimet. Käytännössä selkeä turvatoimiliite auttaa tekemään nämä sitoumukset yksilöidyiksi.
Toimenpiteiden tavoitteena ei ole luvata mahdotonta täydellistä turvallisuutta. EU-tuomioistuin vahvisti asiassa C-340/21, ettei ulkopuolisen onnistunut tietomurto yksin osoita suojausten olleen epäasianmukaisia. Asianmukaisuus arvioidaan konkreettisesti; rekisterinpitäjällä on myös kyseisen vahingonkorvauskanteen yhteydessä näyttötaakka toimiensa asianmukaisuudesta. Pelkkä asiantuntijalausunto ei ole automaattisesti välttämätön ja riittävä näyttö. C-340/21, kohdat 39–64.
Rajaa mallin kohde ennen turvatoimien luetteloa
Hankevirta käsittelee asiakasprojektien yhteyshenkilöitä, työntekijöiden tehtäviä, projektiviestejä ja sopimusliitteitä. Tässä kuvauksessa kohteena ovat projektipalvelu, yrityksen hallitut kannettavat ja niistä tehtävät tiedonsiirrot. Palkanlaskenta ja rekrytointi eivät kuulu samaan kuvaukseen. Niille on omat käsittelyt ja niihin sopivat suojaukset.
Rajaus ei tarkoita, että riippuvuudet unohdetaan. Projektipalvelun tunnistus, varmuuskopiointi ja ulkoinen ylläpito merkitään mukaan niiltä osin kuin ne suojaavat kohteen tietoja. Järjestelmäkartoitus osoittaa yhteydet, ja käsittelytoimien seloste kuvaa henkilötietojen käsittelyä laajemmin. Turvatoimiasiakirja täydentää molempia.
Esimerkin keskeiset riskit ovat väärän projektin tietojen näyttäminen käyttäjälle, kannettavan katoaminen, ulkoisen ylläpidon liian laaja pääsy sekä projektitietojen palautumisen epäonnistuminen. Näin luettelon järjestys syntyy käsittelystä. Serverihuoneen kulkukortti ei ole yrityksen oma toimi, jos sen palvelu toimii kokonaan ulkoisen toimittajan ympäristössä.
Täytetty turvatoimimalli
Seuraava kokonaisuus on harjoitusesimerkki. Sen aikavälit ja vastuunjako ovat Hankevirran omia valintoja. Omassa asiakirjassa toteutukseksi merkitään vain se, mikä on käytössä ja jonka kattavuus on selvitetty.
Kohde ja vastuut. Asiakasprojektien hallinta, versio 1.2. Liiketoiminnan omistaja on projektijohtaja. Tekninen vastuuhenkilö on IT-vastaava. Asiakirjan ylläpitäjä kokoaa muutokset, mutta ei hyväksy yksin liiketoiminnan jäännösriskejä. Palveluntarjoajan osuus viittaa erilliseen, kyseistä palvelua koskevaan selvitykseen.
Luottamuksellisuus ja käyttöoikeudet. Työntekijät käyttävät henkilökohtaisia tunnuksia. Projektin omistaja hyväksyy jäsenyyden; asiakas näkee vain oman projektinsa. Ylläpidon oikeus on erillinen tavallisesta käyttäjäroolista. Työsuhteen päättymistieto käynnistää tunnuksen sulkemisen ja aktiivisten istuntojen käsittelyn. Todentamisessa poistettu käyttäjä ei saa enää projektia auki, eikä ulkopuolinen testitunnus näe toisen asiakkaan projektia.
Kirjautuminen ja palautus. Etäkäyttö ja ylläpito käyttävät valittua monivaiheista tunnistautumista. Kadonneen kirjautumisvälineen korvaaminen edellyttää dokumentoitua henkilön varmistamista; pelkkä uusi puhelinnumero tukipyynnössä ei riitä. Poikkeustunnukset inventoidaan ja niiden käyttöä seurataan. Viimeisessä tarkistuksessa yksi vanha palvelutunnus jäi selvittämättä, joten sitä ei merkitä samojen suojausten kattamaksi.
Laitteet ja salaus. Hallittujen kannettavien levysalaus on käytössä. Palautusavaimet ovat erillisessä hallinnassa, johon projektikäyttäjä ei pääse. Projektipalvelun yhteydet suojataan TLS:llä, ja sisäisten yhteyksien varmennus on erikseen tarkistettu. Salauksen väite ei kata asiakkaan myöhemmin omalle laitteelleen tallentamaa kopiota. Tämän tiedon jakamiseen sovelletaan sovittuja asiakasohjeita.
Eheys ja muutosten seuranta. Projektitietojen keskeisistä muutoksista jää tapahtuma, jossa näkyvät tekijä, kohde ja aika. Käyttöliittymän roolit ja palvelimen valtuutukset tukevat samaa rajausta. Harjoituksessa väärään projektiin kohdistuva päivitys torjutaan. Lokin tarkoitus, pääsy ja säilytys on määritelty erikseen, eikä siihen tallenneta tarpeettomia liitteiden sisältöjä.
Saatavuus ja palautuminen. Esimerkissä varmuuskopiointi tehdään päivittäin erilliseen hallintaan. Liiketoiminnan omistaja on hyväksynyt kyseiselle palvelulle kahdeksan tunnin palautumistavoitteen ja enintään yhden vuorokauden tietomenetystavoitteen. Nämä ovat toimintaa koskevia tavoitteita, eivät GDPR:n yleisiä määräaikoja. Viimeisin rajattu palautusharjoitus palautti projektin ja sen liitteet, mutta koko palvelun tavoiteaikaa ei vielä osoitettu.
Tietojen erottaminen ja poistaminen. Kehityksessä käytetään erillistä harjoitusaineistoa. Tuotantokantaa ei kopioida automaattisesti kehittäjien laitteille. Asiakkaan projektin sulkeminen käynnistää säilytystarpeen arvioinnin ja sovitut poistot; kirjalliseen riitaan liittyvä rajattu aineisto käsitellään erikseen. Poistotyön tulosta tarkistetaan myös vientitiedostoista ja palvelun ulkopuolisista kopioista.
Henkilöstö ja poikkeamat. Työntekijä saa oman roolinsa tiedonkäsittelyohjeet ennen pääsyn avaamista. Epäilyttävä tietojen näkyminen ilmoitetaan nimetylle vastuuhenkilölle. Tämä huolehtii rajaamisesta, selvityksen käynnistämisestä ja tietoturvaloukkauksen arvioinnista. Ohje sisältää varahenkilön tilanteeseen, jossa ensisijainen vastuuhenkilö ei ole tavoitettavissa.
Tarkistukset ja avoimet kohdat. Hankevirta tarkistaa omassa mallissaan projektiryhmien oikeudet kolmen kuukauden välein sekä olennaisen muutoksen yhteydessä. Palautuminen harjoitellaan merkittävän alustamuutoksen jälkeen ja erikseen sovitussa rytmissä. Avoimina ovat vanhan palvelutunnuksen poistaminen ja koko palvelun palautusajan osoittaminen. Molemmilla on vastuuhenkilö, tavoitepäivä ja hyväksymiskriteeri.
Toimenpide, näyttö ja puute eivät ole sama asia
Mallin käyttöoikeuksia koskeva kohta voidaan tiivistää seurantataulukoksi. Siinä vältetään merkintää ”valmis” silloin, kun valmiina on vasta ohje tai hankittu lisenssi.
| Suojaus | Nähty näyttö | Johtopäätös |
|---|---|---|
| Asiakkaiden erottaminen | Kahden testiasiakkaan käyttöoikeustarkistus | Tarkastettu toiminto rajaa näkyvyyden oikein |
| Käyttäjän poistuminen | Tunnuksen sulkeminen ja istunnon päättymisen tarkistus | Menettely toimii tarkastetussa tilanteessa |
| Koko palvelun palautuminen | Yhden projektin palautusraportti | Ei vielä näyttöä koko palvelun tavoiteajasta |
| Kaikkien ylläpitotunnusten vahva suojaus | Asetuskuva ja yksi tuntematon palvelutunnus | Kattavuus avoin, lisäselvitys ennen hyväksyntää |
Tämä ero vaikuttaa päätökseen. Jos asiakasprojektien pääsyä ei olisi rajattu oikein, uuden asiakkaan lisäämistä ei hyväksyttäisi ennen korjausta. Sen sijaan yksittäisen dokumentointimerkinnän puuttuminen voi vaatia täydennyksen jo toimivasta suojauksesta. Molemmat käsitellään, mutta niiden käytännön seuraukset eivät ole samat.
Kyberriskien arviointi auttaa määrittämään, mitä puute mahdollistaa. Tekninen palautumissuunnitelma puolestaan täsmentää, miten palautumistavoite todennetaan. Malliin kannattaa viitata näihin yksityiskohtiin sen sijaan, että koko ohje kopioidaan jokaiseen sopimukseen.
Miten toimittajan turvatoimet arvioidaan?
Käsittelijää valittaessa rekisterinpitäjän on saatava riittävät takeet asianmukaisista toimista. Hankevirta pyytää palvelukohtaisen kuvauksen, sen rajauksen ja tarpeelliset todisteet. Sertifikaatin nimi ei yksin kerro, kattaako arviointi käytetyn palvelun, oikean organisaation ja kyseisen käsittelyn.
Toimittajan vastaus ”asiakas vastaa käyttöoikeuksista” ei poista palvelun oman asiakaserottelun arviointia. Vastaavasti toimittajan vahva infrastruktuuri ei korjaa Hankevirran itse jakamaa avointa projektikutsua. Vastuunjakoon kirjataan, kuka asettaa suojauskäytännön, kuka toteuttaa sen ja kuka havaitsee virheen.
Jos toimittaja on käsittelijä, sovitaan 28 artiklan mukainen käsittelysopimus. Kaikkia ulkoisia palveluntarjoajia ei luokitella käsittelijöiksi automaattisesti: roolien määritys tehdään todellisen toiminnan perusteella. Mahdollinen siirto kolmanteen maahan ratkaistaan lisäksi omassa arvioinnissaan, eikä hyvä turvatoimiluettelo yksin muodosta siirtoperustetta.
Millaisia yksityiskohtia asiakirjaan kuuluu?
Jaettavassa kuvauksessa kerrotaan konkreettinen toteutus, kattavuus ja vastuut. Siihen ei liitetä yksityisiä avaimia, palautuskoodeja tai suoria tuotantotunnuksia. Sisäinen todentamisaineisto voi olla tarkempi, mutta myös sen pääsy rajataan. Asiakkaan on voitava arvioida suojausta ilman, että turvallisuuden arviointi itsessään paljastaa salaisuuksia.
Sana ”salaus” täsmennetään kertomalla, mitä tietoa ja yhteyttä se suojaa sekä kuka hallitsee avaimia. Salauksen ja avainten hallinnan opas auttaa kuvauksen laatimisessa. Yhteyksien osalta TLS-asetusten ja varmenteiden tarkistus erottaa ulkoisen yhteyden sisäisistä osista. Asetusnumeron kopioiminen ilman kattavuustietoa ei tuota samaa näyttöä.
Turvatoimi voi myös kerätä uusia henkilötietoja. Henkilöstön tai asiakkaiden laaja seuranta ei muutu tarpeelliseksi pelkällä turvallisuustarkoituksen nimeämisellä. EDPB:n 4/2019-ohje yhdistää turvallisuuden muun muassa minimointiin, rajattuun pääsyyn ja koko elinkaaren suojauksiin. EDPB:n ohje sisäänrakennetusta tietosuojasta, kohdat 83–85.
Tarkista kokonaisuus muutoksen jälkeen
Kun Hankevirta ottaa käyttöön uuden tiedostoviennin, se tarkistaa, muuttuuko asiakkaiden erottaminen, lokitus tai poistaminen. Vanhassa kuvauksessa kaikki tiedot pysyivät projektipalvelussa; uusi vienti luo kopion paikalliselle laitteelle. Tämä muutos kirjataan sekä toimintaohjeeseen että turvatoimien kattavuuteen.
Tarkistusrytmin tulee sopia käsittelyyn ja muutoksiin. Vuosisuunnitelma voi auttaa järjestämään työn, mutta sitä ei käytetä syynä lykätä havaittua olennaista puutetta seuraavaan määräpäivään. Tietoturvan perustoimet ylläpitävät käytännön toteutusta ja osoitusvelvollisuuden dokumentaatio säilyttää päätöksen perustelut.
Valmis kuvaus kertoo lukijalle rehellisesti nykytilan. Hankevirran versiossa yhden projektin palautus on todettu, koko palvelun palautumisaika on avoin ja vanha palvelutunnus odottaa sulkemista. Kun nämä asiat valmistuvat, asiakirjaan päivitetään havainto ja hyväksyntä. Näin mallista tulee käytännön toiminnan kuvaus, jota voidaan käyttää myös vaikean kysymyksen tai häiriön selvittämiseen.