Ashio whistleblowing software

Oct 9, 2026

Whistleblowing-kanavan tietoturva: mitä pk-yrityksen pitää vaatia

Whistleblowing-kanavan tietoturva: mitä pk-yrityksen pitää vaatia

Whistleblowing-kanavaa valitsevan pk-yrityksen tietoturvavaatimukset muodostuvat neljästä toisiinsa kytkeytyvästä osasta: salaus ja tiedon sijainti, anonymiteetin tekninen toteutus, käyttöoikeudet sekä muuttumaton lokitus, joka kestää auditoijan tarkastelun. Kun nämä neljä aluetta on määritelty vaatimuksina ennen hankintapäätöstä, toimittajia voi verrata tasapuolisesti ja riskit näkyvät kirjallisina, eikä niitä tarvitse arvuutella myöhemmin.

Sisällysluettelo

Keskeiset havainnot

  • Salaus ei ole valinta vaan lähtökohta: whistleblowing-kanavan on salattava tiedot päästä päähän selaimessa, jotta edes palveluntarjoaja ei pääse niihin käsiksi.
  • Tiedon sijainti ratkaisee lain noudattamisen: EU:ssa ja Sveitsissä isännöity data täyttää GDPR:n ja kansallisen tietosuojalain vaatimukset, kolmansissa maissa oleva data vaatii erillisen arvioinnin.
  • Anonymiteetti on tekninen, ei markkinointitermi: pseudonymisointi ja täysi anonymiteetti ovat eri asioita, ja vain jälkimmäinen suojaa ilmoittajaa jäljittämiseltä.
  • Auditointi edellyttää lokia, johon voi luottaa: muuttumaton, vientivalmis loki on ainoa keino osoittaa 7 päivän kuittauksen ja 3 kuukauden palautteen määräaikojen toteutuminen.
  • Hankinnassa vaaditaan kirjallinen todiste: pelkkä toimittajan suullinen vakuus sertifikaatista ei riitä, vaan pk-yrityksen on pyydettävä sertifikaatti, tietoturva-arkkitehtuurin kuvaus ja käsittelysopimus nähtäväkseen.

Mitä tietoturvaa whistleblowing-kanava oikeasti vaatii

Whistleblowing-kanava on järjestelmä, jossa käsitellään erityisen arkaluonteisia tietoja: ilmoittajan henkilöllisyys, kohdehenkilöt, todistusaineisto ja usein terveyteen, talouteen tai turvallisuuteen liittyviä seikkoja. EU:n yleinen tietosuoja-asetus (GDPR) luokittelee nämä tiedot erityisryhmään kuuluviksi, ja tietomurto voi johtaa sekä hallinnollisiin seuraamuksiin että ilmoittajan kostotoimiin. Siksi vaatimuslista ei saa jäädä yleiselle tasolle "salattu ja turvallinen", vaan sen on eriteltävä salauksen taso, tiedon sijainti, pääsynhallinta ja todennettavissa oleva lokitus. Tietoturva on myös ilmoittajalle näkyvä lupaus: jos kanava ei vaikuta teknisesti uskottavalta, ilmoituksia ei yksinkertaisesti tule.

Salaus, hosting ja tiedon sijainti: mitä pk-yrityksen on kysyttävä

Whistleblowing-kanavan tietoturva alkaa salauksesta: ilmoittajan selaimessa tiedot on salattava päästä päähän, jolloin palvelin säilyttää vain salattua tekstiä eikä pysty lukemaan sisältöä. Tämä eroaa perinteisestä HTTPS-yhteydestä, joka suojaa vain liikennettä, mutta jättää tiedon selväkieliseksi palvelimelle. Kun arkkitehtuuri on rakennettu niin, ettei edes toimittaja pääse selväkieliseen dataan käsiksi, tietomurto ei paljasta ilmoittajia.

Toinen kysymys on tiedon fyysinen sijainti. EU:n ulkopuolelle tallennettu data voi siirtää henkilötietoja kolmanteen maahan, mikä vaatii erillisen oikeusperustan GDPR:n mukaan. Pk-yrityksen on varmistettava, että palveluntarjoaja ilmoittaa kirjallisesti, missä maassa data säilytetään, ja että tämä maa on joko EU:n jäsenvaltio tai ETA-alue, tai että käytössä on SCC-vakiosopimuslausekkeet tai muu hyväksytty siirto-oikeusperusta. Sveitsiläinen hosting on yksi varteenotettava vaihtoehto, koska Sveitsi tunnustetaan riittäväksi tietosuojan tasoksi EU-komission päätöksellä. Tiedon sijainnin voi tarkistaa toimittajan Tietoturva & GDPR-yhteensopivuus-sivulta ennen sopimuksen allekirjoittamista.

Miten sijainnin voi todentaa käytännössä?

Todentaminen tapahtuu kolmella asiakirjalla: sopimusliitteellä, jossa mainitaan tallennusmaa, isännöitsijän tarjoamalla kolmannen osapuolen tarkastusraportilla sekä toimittajan omalla tietosuojaselosteella. Jos jokin näistä puuttuu, sijainti on epäselvä eikä GDPR-vaatimusta voi osoittaa täytetyksi. Toimittajan on pystyttävä nimeämään datakeskus, jossa varmuuskopiot sijaitsevat, ja kertomaan, miten varmuuskopioiden salaus on järjestetty.

Anonymiteetin toteutus: pseudonymisointi vs. täysi anonymiteetti

Whistleblowing-järjestelmän anonymiteetti tarkoittaa kahta eri asiaa, jotka kannattaa erottaa toisistaan. Pseudonymisoinnissa ilmoittajan tunniste korvataan tunnisteella, mutta yhteys voidaan palauttaa erillisellä avaimella. Täydessä anonymiteetissä ilmoittajasta ei kerätä lainkaan tunnistetietoja: ei IP-osoitetta, ei evästeitä, ei laitetunnisteita, ja yhteyttä ilmoittajaan ei voida palauttaa edes toimittajan toimesta. Jälkimmäinen on ainoa taso, joka suojaa ilmoittajaa jäljittämiseltä myös silloin, kun viranomainen tai tuomioistuin pyytää tietoja.

Käytännössä ero näkyy siinä, miten ilmoittaja pääsee kanavaan. Täysin anonyymi kanava ei vaadi kirjautumista, ei tallenna evästeitä eikä kirjaa IP-osoitetta. Viestintä ilmoittajan ja käsittelijän välillä tapahtuu kertakäyttöisen, salatun linkin kautta, joka syntyy ilmoituksen yhteydessä. Tämä on teknisesti eri ratkaisu kuin sisäinen tikettijärjestelmä, jossa ilmoittaja saa käyttäjätunnuksen. Pseudonymisointi riittää harvoin tilanteissa, joissa ilmoittaja epäilee kohteena olevan esihenkilön tai johdon.

Käyttöoikeudet, lokitus ja jäljitettävyys auditoijalle

Whistleblowing-kanavan lokitus ja käyttöoikeudet ovat se osa, joka joko pelastaa tai kaataa auditoinnin. Käsittelijöiden pääsy ilmoituksiin on rajoitettava roolipohjaisesti: vain nimetyt henkilöt näkevät tapaukset, ja heidän toimintonsa on kirjattava järjestelmään. Lokin on oltava muuttumaton, jotta kukaan ei voi jälkikäteen poistaa merkintöjä käsittelystä. Tämä ei ole tekninen yksityiskohta vaan suoraan EU:n ilmoittajansuojeludirektiivin 2019/1937 vaatimus, ja Suomen ilmoittajansuojalaki velvoittaa siihen myös yksityisen sektorin vähintään 50 työntekijän organisaatioita.

Auditoijalle on pystyttävä osoittamaan kolme asiaa: kuka avasi ilmoituksen, milloin se kuitattiin ilmoittajalle (7 päivän määräaika) ja milloin annettiin palaute (3 kuukauden määräaika). Jos jokin näistä puuttuu lokista, auditoija tulkitsee määräajan ylittyneeksi, vaikka todellisuudessa vastaus olisi annettu. Siksi lokin on tuotava määräajat näkyviksi eikä haudata niitä kalenterimerkintöihin. Lokin viennin on onnistuttava vakiomuotoihin, jotta tarkastus ei vaadi toimittajan omaa työkalua.

Tarkistuslista: 8 kohtaa, jotka pk-yrityksen on vaadittava kirjallisesti

Tarkistuslista: 8 kohtaa, jotka pk-yrityksen on vaadittava kirjallisesti Ennen sopimusta toimittajalta on pyydettävä kirjallinen vastaus jokaiseen seuraavaan kohtaan. Pelkkä suullinen vakuus ei riitä, vaan dokumentin on oltava liitettävissä hankintasopimukseen.

  1. Päästä päähän -salaus selaimessa. Salausalgoritmi (esim. AES-256-GCM) ja avainten käsittely on kuvattava. Palvelimen on säilytettävä vain salattua tekstiä.
  2. Tiedon sijainti EU:ssa tai Sveitsissä. Datakeskuksen maa ja varmuuskopioiden sijainti ilmoitetaan sopimusliitteessä.
  3. Täysi anonymiteetti ilmoittajalle. Ei IP-lokitusta, evästeitä tai tunnistetietoja. Kaksisuuntainen viestintä kertakäyttöisen salatun linkin kautta.
  4. ISO 27001 -sertifioitu isännöinti. Voimassa oleva sertifikaatti toimitetaan kopiona ja sen voimassaolo tarkistetaan sertifioijan rekisteristä.
  5. GDPR-vaatimustenmukaisuus. Käsittelysopimus (DPA) sisältää käsittelyperusteen, alikäsittelijät ja tietoturvaliitteen. Taustat voi tarkistaa GDPR ja ilmiantaminen-sivulta.
  6. Roolipohjaiset käyttöoikeudet. Vain nimetyt käsittelijät pääsevät ilmoituksiin, ja pääsy tarkistetaan neljän silmän periaatteella.
  7. Muuttumaton toimintaloki. Lokista näkyvät avaaminen, kuitaukset, vastaukset ja viennit. Loki on säilytettävä vähintään laissa vaaditun ajan.
  8. Määräaikojen seuranta. 7 päivän kuittaus ja 3 kuukauden palaute näkyvät järjestelmässä eivätkä jää kalenterivastuulle.

Hinnoittelun näkyvyys kannattaa tarkistaa erikseen, jotta välttyy piilokustannuksilta. Käyttäjäkohtaiset lisenssit, jotka kasvavat ilmoitusten määrän myötä, voivat nostaa kokonaiskustannuksen moninkertaiseksi ensimmäisen vuoden aikana. Kiinteä kuukausihinta on pk-yritykselle ennustettavampi vaihtoehto, ja sitä voi verrata pricing-sivun rakenteeseen.

Tämän vaatimuslistan rinnalle on hyvä lukea erillinen taustakappale whistleblowingin yksityisyydestä sekä pilviympäristöjen yleisestä vaatimustenmukaisuudesta, jotta oman tietoturvakontrollin konteksti pysyy selkeänä: whistleblowing yksityisyys ja Cloud‑Sicherheit und Compliance.

Käytännön toteuttajaksi pk-yritys voi valita joko sisäisen järjestelmän ylläpidon, yleisen tikettityökalun räätälöinnin tai siihen tarkoitetun ohjelmiston, joka hoitaa anonymiteetin, salauksen ja lokituksen valmiina. Sisäinen rakentaminen vaatii oman kryptografisen toteutuksen ja auditoitavan ympäristön, mikä harvoin on pk-yritykselle järkevää. Valmisohjelmisto sopii silloin, kun vaatimukset ovat selvillä ja toimittaja kykenee ne kirjallisesti todentamaan. Eräs tällaisista valmisratkaisuista on Ashio, joka tarjoaa anonyymin ilmoituskanavan päästä päähän -salattuna ja Sveitsissä isännöitynä, eikä sen käyttöönotto edellytä oman infrastruktuurin ylläpitoa. Kokeilun voi aloittaa sign up-sivulta ilman sitoutumista.

Usein kysytyt kysymykset

Mikä on pienin hyväksyttävä salausstandardi whistleblowing-kanavalle?

Pienin hyväksyttävä taso on päästä päähän -salaus selaimessa AES-256-GCM-luokan salausalgoritmilla, jolloin palvelin ei näe selväkielistä sisältöä. Pelkkä HTTPS-yhteys ei riitä, koska se suojaa vain liikennettä palvelimelle asti.

Tarvitseeko pk-yritys aina EU-direktiivin mukaisen kanavan?

EU:n ilmoittajansuojeludirektiivi 2019/1937 velvoittaa vähintään 50 työntekijän yksityisen sektorin organisaatiot perustamaan ilmoituskanavan, ja kansallinen lainsäädäntö on saattanut asettaa matalamman rajan. Pelkkä sisäinen sähköpostilaatikko ei täytä vaatimusta, koska anonyymin kanavan on oltava erillinen järjestelmä.

Miten anonymiteetin voi todentaa ennen sopimusta?

Todentaminen tapahtuu teknisellä kuvauksella ja käytännön testillä. Toimittajan on kerrottava kirjallisesti, ettei järjestelmä kirjaa IP-osoitteita, evästeitä tai laitetunnisteita, ja tämä on varmistettavissa esimerkiksi selaimen kehittäjätyökaluilla.

Onko ISO 27001 -sertifikaatti pakollinen?

Sertifikaatti ei ole lain kirjaimellinen vaatimus, mutta käytännössä se on ainoa kolmannen osapuolen vahvistama todiste siitä, että isännöitsijällä on dokumentoitu tietoturvan hallintajärjestelmä. Ilman sertifikaattia pk-yrityksen on luotettava toimittajan omaan vakuutukseen, mikä ei auditoinnissa paina.

Kauanko ilmoitukseen liittyvää dataa saa säilyttää?

EU:n ilmoittajansuojeludirektiivi ei aseta tarkkaa säilytysaikaa, mutta kansallinen lainsäädäntö ja GDPR:n minimointiperiaate rajoittavat säilytyksen tapauskohtaisen tarpeen mukaan. Tyypillinen enimmäisaika on 2–5 vuotta tapauksen ratkaisemisen jälkeen, ellei laissa toisin säädetä.

Lähteet