By · Last updated 2026-06-05

Takaisin BlogiinGDPR & Vaatimustenmukaisuus

GDPR-auditointi epäonnistui: pirstoutuneet henkilötietotyökalut

Tilintarkastajasi pyytää henkilötietojen tunnistamisen kontrolleista tietoa. 'Käytämme viittä eri työkalua' ei ole vastaus, jonka he haluavat kuulla. Siksi alustakohtainen johdonmukaisuus on tärkeää.

June 5, 20266 min lukuaika
GDPR auditcompliance controlsPII tool consistencyDPA investigationtechnical measures

GDPR-auditointi epäonnistui: pirstoutuneet henkilötietotyökalut

Päivitetty vuodelle 2026.

Tilintarkastajasi esittää yhden kysymyksen: "Mitä teknisiä kontrolleita henkilötietojen suojaamiseen käytetään?" Väärä vastaus: "Käytämme viittä eri työkalua." Tässä syy siihen, miksi viiden työkalun käyttö epäonnistuu GDPR-auditoinneissa — ja miltä siisti vastaus näyttää.

Auditointihetki

Tietosuojaviranomaisen tutkija tapaa vaatimustenmukaisuusvastaavan. Tietosuojaviranomainen tutkii rekisteröidyn tekemää valitusta. Entinen asiakas väittää, että hänen tietojaan on käsitelty virheellisesti.

Kysymys: "Mitä kontrolleita organisaatiollanne on henkilötietojen suojaamiseksi, kun työntekijät käsittelevät niitä?"

Vaatimustenmukaisuusvastaava: "Lakimiehemme käyttävät Word-lisäosaa. Tukihenkilöstö käyttää Chrome-laajennusta. Data-tiimillämme on Python-skripti. Yksittäisiin pyyntöihin kuka tahansa voi käyttää verkkosovellusta."

Tutkija: "Onko nämä sama työkalu? Sama moottori? Sama kattavuus?"

Vaatimustenmukaisuusvastaava: "Ei. Ne toimivat eri tavalla."

Siinä hetkessä auditointi vaikeutuu.

Miksi pirstoutuneet työkalut epäonnistuvat 32 artiklan kohdalla

GDPR:n 32 artikla edellyttää "asianmukaisia teknisiä ja organisatorisia toimenpiteitä". Standardilla on kaksi osaa.

Riskiin soveltuva. Toimenpiteiden on vastattava riskiä. Monien työnkulkujen kautta käsiteltäville henkilötiedoille johdonmukainen henkilötietojen tunnistus on pakollista. Tunnistus, joka vaihtelee työkaluittain, ei täytä tätä vaatimusta.

Todistettavuus. Toimenpiteiden on oltava todistettavissa. 5(2) artikla — vastuullisuusperiaate — edellyttää, että rekisterinpitäjät "pystyvät osoittamaan vaatimustenmukaisuuden". Se tarkoittaa johdonmukaisen kontrollin näyttöä. Ei parasta mahdollista. Johdonmukaista.

Hajautettu välineistö epäonnistuu todistamisen osalta. Työkalu A tunnistaa 285 entiteettityyppiä. Työkalu B tunnistaa 50. Työkalu C tunnistaa 200 mutta eri kynnysarvoilla. Et voi todistaa johdonmukaista suojausta tuolla pinolla. Voit vain osoittaa, että joitain työkaluja käytettiin joissain yhteyksissä.

Tietosuojaviranomaisen havainto hajautetusta välineistöstä kuuluu: "Henkilötietojen suojauksen tekniset kontrollit ovat epäjohdonmukaisia eri työnkulkujen välillä. Tämä luo kattavuusaukkoja ja estää keskitetyn auditointipolun tarkastelun."

Kattavuusaukkojen löytämisongelma

Et usein tiedä, missä kattavuusaukkosi ovat, ennen kuin rikkomus tapahtuu.

Oletetaan, että Työkalu B (data-tiimin käyttämä) ei tunnista EU:n kansallisia henkilötunnusnumeroita. Työkalu A (lakimiesten käyttämä) tunnistaa. Tämä aukko on näkymätön normaalin työn aikana. Tiedostoja käsitellään. Hälytyksiä ei tule. Mikään ei näytä väärältä.

Aukko paljastuu, kun:

  • EU:n kansallinen henkilötunnus ilmestyy tiedostoon, jonka data-tiimi käsitteli
  • Tuo tiedosto jaetaan ilman kontrolleja
  • Rekisteröity löytää altistumisen ja tekee GDPR-valituksen

Nyt tietosuojaviranomainen paljastaa aukon. Data-tiimi käytti työkalua, jolla oli erilainen kattavuus kuin muilla tiimeillä. Aukko, joka olisi pitänyt löytää ja sulkea.

Yhtenäinen kattavuus korjaa tämän. Samat entiteettityypit tunnistetaan kaikissa yhteyksissä. Aukot tulevat näkyviksi — nolla tunnistusta entiteetistä X missään työnkulussa — sen sijaan, että ne olisivat piilossa.

Katso GDPR 32 artikla ja tekoälytyökalujen seuranta siitä, mitä tilintarkastajat etsivät teknisistä kontrolleista.

Miltä siisti vaatimustenmukaisuusvastaus näyttää

Yhtenäisen alustan omaava vaatimustenmukaisuusvastaava vastaa eri tavalla.

"Käytämme yhtä henkilötietojen tunnistusalustaa kaikissa työnkuluissa. Lakimiehet, tukiagentit ja data-insinöörit käyttävät samaa tunnistusmoottoria. Käyttöliittymät eroavat — Word-lisäosa, Chrome-laajennus, työpöytäsovellus — mutta malli ja asetus ovat samat. Kaikki käsittely kirjautuu keskitettyyn auditointipolkuun. Asetuksemme kattaa 285+ entiteettityyppiä lainkäyttöaluekohtaisilla esiasetuksilla. Voin hakea minkä tahansa ajanjakson tiedot tarpeen mukaan."

Tämä vastaus on:

  • Tarkka. Se nimeää alustan ja selittää monialaisen asennuksen.
  • Johdonmukainen. "Sama tunnistusmoottori" vastaa kattavuushuoleen suoraan.
  • Todistettavissa. Keskitetty auditointipolku tarkoittaa, että todisteet ovat valmiina pyydettäessä.

Kun tutkija pyytää auditointipolkua tietylle rekisteröidylle, pyyntö täytetään välittömästi.

Alustakohtaisen johdonmukaisuuden standardi

Vahvan 32 artiklan aseman saavuttamiseksi nämä ovat vähimmäisvaatimukset.

Tunnistuksen johdonmukaisuus:

  1. Sama tunnistusmalli tai -rajapinta kaikilla alustoilla
  2. Sama entiteettityyppien kattavuus — jos verkkosovellus tarkistaa 285 entiteettiä, myös työpöytäsovelluksen on tehtävä niin
  3. Samat luottamuksen kynnysarvot — mikään työkalu ei ole löyhempi tai tiukempi saman entiteettityypin suhteen
  4. Samat korvausmerkinnät samoille entiteettityypeille
  5. Keskitetty auditointipolku kaikilla alustoilla

Dokumentaatiovaatimukset:

  • Konfiguraatiotilannevedos: nykyinen entiteettikattavuus ja kynnysarvot
  • Muutoshistoria: mitä muuttui ja milloin
  • Kattavuustodiste: kaikki alustat jakavat saman asetuksen

Voit rakentaa tämän monitoimiselle välineistölle. Mutta se vaatii muodollista konfiguraationhallintaa ja säännöllisiä alustakohtaisia auditointeja. Yksi alusta tekee vastauksesta yksinkertaisen: "Tässä on asetus. Se pätee kaikkialla. Tässä on auditointipolku."

Laajempi katsaus alustakohtaiseen johdonmukaisuuteen: Alustakohtainen henkilötietojen vaatimustenmukaisuus: Mac, Linux, Windows.

Käytännön siirtymä: hajautetusta yhtenäiseen

Vaihe 1: Kartoita työkalut ja kattavuus

  • Listaa jokainen työkalu tiimeittäin ja työnkuluittain
  • Dokumentoi, mitä henkilötietotyyppejä kukin työkalu tunnistaa
  • Löydä aukot — mitä Työkalu A tunnistaa, mitä Työkalu B jättää huomaamatta?

Vaihe 2: Määritä kattavuusstandardi

  • Velvollisuuksiesi perusteella — GDPR:n entiteettityypit, HIPAA PHI, CCPA-kategoriat
  • Aseta yksi standardi, joka pätee kaikkiin työnkulkuihin

Vaihe 3: Valitse yhtenäinen alusta

  • Voiko se ottaa käyttöön verkossa, työpöydällä, Wordissa ja selaimessa?
  • Täyttääkö se kattavuusstandardisi?
  • Tarjoaako se keskitetyn auditointipolun?

Vaihe 4: Siirrä

  • Aloita suurimman riskin työnkuluista
  • Siirrä tiimi kerrallaan ja poista vanhat työkalut käytöstä, kun käyttäjät siirtyvät
  • Kirjaa migraatio vaatimustenmukaisuuslokiisi

Hajautettu välineistö on yksi yleisimmistä GDPR-kontrolliaukoista, joita löydetään auditoinneissa. Katso, miten se ilmenee hajautetuissa tiimeissä: Etätyö ja GDPR: Alustan epäjohdonmukaisuus.

Lähteet

Valmiina suojaamaan tietojasi?

Aloita PII-anonymisointi yli 285 entiteettityypillä 48 kielellä.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.