By · Last updated 2026-05-24

Vissza a BlograGDPR & Megfelelés

GDPR DSAR-megfelelőség nagy léptékben: 200 kérelem havonta

A GDPR 15. cikke szerinti érintetti hozzáférési kérelmek száma évente 40–60%-kal nő. Szervezetek havonta százakat kapnak belőlük. A kötegelt PII-szerkesztés 10-szeres feldolgozási sebességet tesz lehetővé.

May 24, 20268 perc olvasás
DSAR processingGDPR Article 15data subject access requestright of accessbatch redaction

GDPR DSAR-megfelelőség nagy léptékben: 200 kérelem feldolgozása havonta csapat felvétele nélkül

A GDPR 15. cikke biztosítja az érintett számára a jogot, hogy másolatot kapjon a szervezet által tárolt összes személyes adatáról. A 30 napos válaszadási határidő (összetett kérelmeknél 90 napra meghosszabbítható) kötelező. A szisztematikus DSAR-mulasztás bírsága nem elméleti: a Vodafone Spanyolország 2021-ben 1,2 M €-s bírságot kapott DSAR-mulasztásokért. Egy német cég 2023-ban 225 000 €-s bírságot kapott.

A DSAR-ok száma meredeken növekszik. Ahogy az adatjogokkal kapcsolatos nyilvános tudatosság nő — részben az egyéneket tömeges DSAR-ok benyújtásában segítő adatvédelmi érdekképviseleti szervezetek tevékenysége nyomán — az egykor évente 10 DSAR-t kapó szervezetek ma havonta 200-at kapnak. A 10 kérelemre méretezett kézi folyamat erőforrásai nem tudják automatizálás nélkül felszívni a 20-szoros növekedést.

Mit jelent a DSAR-feldolgozás valójában?

A GDPR 15. cikke nem csupán azt igényli, hogy „igen, rendelkezünk adatokkal Önről”. Másolatot kell átadni ezekből az adatokból. A komplexitás:

Adatazonosítás: Az érintettről az összes rendszerben tárolt személyes adatok felkutatása — CRM, e-mail, support ticketek, marketingplatformok, elemzőeszközök, HR-rendszerek (ha az érintett munkavállaló). A gyakorlatban ez rendszerközi lekérdezéseket igényel, amelyeket a jogi és az IT-részlegnek kell koordinálnia.

Harmadik féltől szóló szerkesztés: Az érintettnek átadott másolat nem tartalmazhat más személyek személyes adatait. Ha egy support ticketben szerepel a support ügynök teljes neve és személyes e-mail-címe, ezeket szerkeszteni kell, mielőtt a ticket bekerül a DSAR-válaszba. Ha a rendelési előzményekben szerepel egy másik ügyfél neve (közös szállítási cím, ajándékvásárlás), azt a nevet el kell távolítani.

Ez a harmadik féltől szóló szerkesztés az, ahol a kötegelt feldolgozás drámai hatékonyságnövelést hoz. Egy e-kereskedelmi platform, amely havonta 200 DSAR-t dolgoz fel, mindegyik 15–30 rendelési előzményből, support ticketből és fiókrekordból álló dokumentumcsomóval, havonta 3 000–6 000 dokumentumot állít elő, amelyekből szállítás előtt harmadik féltől szóló PII-szerkesztés szükséges.

Formátumkövetelmények: A GDPR megköveteli, hogy az adatokat „általánosan használt elektronikus formátumban” adják át. A PDF, az egyszerű szöveg vagy a strukturált adatexportok mind elfogadottak. Ha az adatokat strukturált formátumban tárolják, a formátumnak géppel olvashatónak kell lennie.

Időbeli megfelelőség: 30 nap a hitelesített kérelem kézhezvételétől számítva. A 90 napos meghosszabbítás a 30 napon belüli értesítést igényli az érintett felé magyarázattal. A határidők elmulasztása az adatvédelmi hatóságok végrehajtási intézkedéseinek elsődleges alapja.

A DSAR-feldolgozás matematikája

Egy európai e-kereskedelmi platform havonta 200 DSAR-t kap.

DSAR-onkénti dokumentumprofil:

  • Átlagos rendelési előzmény rekordok: 8–12 dokumentum
  • Support ticket rekordok: 3–7 dokumentum
  • Fiók/profilrekordok: 2–4 dokumentum
  • Összesen DSAR-onként: 13–23 dokumentum

Havi összesítés:

  • 200 DSAR × 18 dokumentum (átlag) = 3 600 szerkesztést igénylő dokumentum

Kézi feldolgozási idő:

  • Dokumentum elolvasása és harmadik féltől szóló PII azonosítása: 4–8 perc
  • Kézi szerkesztés: 3–7 perc
  • Összesen dokumentumonként: 7–15 perc
  • 3 600 dokumentum: 420–900 óra/hó

Három-hat teljes munkaidős munkavállaló, aki kizárólag DSAR-szerkesztéssel foglalkozik — csupán a szerkesztési fázishoz, az adatazonosítás vagy a válaszformázás nélkül.

Automatizált kötegelt feldolgozás:

  • 3 600 dokumentum feltöltése kötegekben
  • „DSAR harmadik féltől szóló szerkesztés” előbeállítás alkalmazása (az érintetthez nem tartozó személynevek, e-mailek, telefonszámok)
  • Feldolgozás: 4–8 óra (éjszakai kötegelt feladat)
  • Nem egyértelmű esetek kivételáttekintése: 360 dokumentum (10%) × 15 perc = 90 óra

Kivételáttekintés és válaszelőkészítés: 150–200 óra/hó. 3 teljes munkaidős alkalmazottból 1 teljes munkaidős alkalmazott. Éves munkabér-megtakarítás: körülbelül 120 000–180 000 €.

A titkosítás-majd-szerkesztés munkafolyamat a belső feldolgozáshoz

Azon szervezetek számára, amelyek a belső nyilvántartásaikban meg akarják őrizni a visszaállíthatóságot, miközben szerkesztett külső válaszokat nyújtanak:

Belső feldolgozás (Titkosítás módszer): Ellenőrzött kulcstól tárolj dokumentumokat titkosított PII-vel. Az eredeti adatok visszanyerhető formában megmaradnak. Ez lehetővé teszi az újrafeldolgozást, ha a konfiguráció módosítást igényel, miközben az adatok expozíciójának csökkentése mellett megmaradnak a szervezeti nyilvántartások.

Külső válasz (Szerkesztés módszer): A DSAR-válasz esetén alkalmazzunk visszafordíthatatlan szerkesztést. Az érintett egy tiszta dokumentumot kap, amelyből teljesen eltávolítottuk a harmadik fél személyes adatait — titkosított tokenek, visszafordítható jelölések nélkül.

Ez a kétlépéses megközelítés megőrzi a belső adatintegritást (szükség esetén újrafeldolgozható), miközben megfelelő DSAR-válaszokat állít elő.

Megfelelőségi dokumentáció

A GDPR elszámoltathatósági elvárása (5(2). cikk) megköveteli, hogy a szervezetek bizonyítani tudják a megfelelőséget, ne csupán állítsák azt. A DSAR-feldolgozási dokumentációnak tartalmaznia kell:

  • A kérelem kézhezvételének dátuma és a személyazonosság-ellenőrzés
  • Az adatazonosítási eljárás (melyik rendszereket kérdeztek le, mit találtak)
  • Az alkalmazott szerkesztési kritériumok (milyen entitástípusok, milyen módszer)
  • A válasz átadásának dátuma és formátuma
  • Kivételáttekintési folyamat a kézi döntésekhez

A kötegelt feldolgozás természetes audit-nyomvonalat hoz létre: a feldolgozási naplók megmutatják, melyik dokumentumokat dolgozták fel, milyen konfigurációt alkalmaztak és mikor. Ez a dokumentáció értékes mind a belső elszámoltathatóság, mind az adatvédelmi hatósági megkeresésekre való reagálás szempontjából.

Mennyibe kerülnek a DSAR-mulasztások?

A Vodafone Spanyolország elleni 1,2 M €-s bírság (AEPD, 2021) szisztematikus DSAR-válaszadási hibákat érintett — a 30 napos határidőn belüli nem reagálás, hiányos válaszok és a kérelmek elutasítása előtti nem megfelelő személyazonosság-ellenőrzés.

Egy német céggel szembeni 225 000 €-s bírság (bajor adatvédelmi hatóság, 2023) a DSAR-válaszok késedelmének és a nem megfelelő adatazonosításnak a mintáját érintette — a szervezet nem az összes releváns adatot tartalmazó válaszokat adott.

Mindkét bírság nem egyéni hibákat tükröz, hanem szisztematikus folyamathibákat. Ha a DSAR-ok száma meghaladja a kézi folyamatok kapacitását, szisztematikus hibák következnek. Az automatizálás nem előzi meg az összes DSAR-megfelelőségi hibát, de megszünteti azt a kapacitáskorlátot, amely szisztematikus késedelmet okoz.

Megvalósítási ellenőrzőlista

Az automatizálás előtt:

  • Dokumentálja a DSAR-beáramlási folyamatát
  • Azonosítsa az összes személyes adatot tartalmazó rendszert
  • Hozzon létre adattérképet a rendszerközi lekérdezésekhez

Automatizálás beállítása:

  • Konfigurálja a „DSAR-szerkesztés” előbeállítást a megfelelő entitástípusokkal
  • Határozza meg a kivételkritériumokat (mi igényel emberi áttekintést)
  • Tesztelje 5–10 minta DSAR-on az éles üzembe helyezés előtt

Folyamatos folyamat:

  • Dokumentumok kötegelt feltöltése minden egyes DSAR-hoz vagy napi kötegként
  • Kivételdokumentumok átirányítása emberi áttekintési sorba
  • Válaszcsomagok létrehozása a feldolgozott kimenetből
  • Válasz dátumainak és formátumainak naplózása a megfelelőségi dokumentációhoz

Mikor vezet be a kötegelt feldolgozás új kockázatokat?

Az automatizált kötegelt DSAR-feldolgozás csökkenti a kézi terhelést, de saját megfelelőségi kockázatokat teremt:

A hamis pozitív/negatív arányok nagy léptékben fontosabbak: A PII-detektálás 2%-os hamis negatív aránya (PII, amelyet közzé kellene tenni, de nem találják meg) tolerálható a kézi áttekintésnél, de 50 000 éves DSAR-feldolgozásnál ezernyi hibára fordítódik. A szervezeteknek validálniuk kell a detektálási pontosságot a saját dokumentumtípusaikon, mielőtt az automatizálásra támaszkodnának megfelelőségi döntéseknél.

Harmadik feles feldolgozói lánc összetettsége: A kötegelt DSAR-feldolgozás gyakran több feldolgozón (OCR-szállítók, NLP API-k, felhőalapú tárolás) átáramló adatokat érint. Mindegyik további 28. cikk szerinti megfelelőségi kötelezettségeket és potenciális adattároláshely-problémákat vezet be.

Az automatizált döntések emberi felügyeletet igényelnek: A GDPR 22. cikke korlátozza az érintettekre jogi hatást kifejtő kizárólag automatizált döntéseket. A kötegelt DSAR-feldolgozásnak, amely automatikusan meghatározza, hogy mely adatokat kell közzétenni vagy visszatartani, emberi felülvizsgálati ellenőrzőpontokat kell tartalmaznia.

A dokumentációs overhead az automatizálással együtt nő: Az automatizált feldolgozáshoz részletes adatkezelési tevékenységek nyilvántartásának (ROPA) frissítései, új adatfolyam-dokumentáció és szállítói DPA-k szükségesek. A szervezetek alábecsülik ezt az adminisztratív terhet a kötegelt DSAR-rendszerek tervezésekor.

Összefoglalás

A DSAR-ok száma nem csökken. Ahogy az adatvédelmi jogokkal kapcsolatos tudatosság nő — amelyet az adatvédelmi érdekképviseleti szervezetek, a DSAR-benyújtást automatizáló böngészőbővítmények és a nagy adatvédelmi jogsértések médiavisszhangja gyorsít — a szervezetek várhatóan évi 40–60%-os DSAR-növekedéssel számolhatnak.

A kézi DSAR-feldolgozás nem skálázható. A szerkesztésre szánt három teljes munkaidős alkalmazott nem megfelelőségi stratégia; ez ideiglenes megoldás egy tartósan növekvő problémára. A mechanikus szerkesztési munkát elvégző kötegelt automatizálás — felszabadítva a megfelelőségi munkatársakat az adatazonosítás, a kivételáttekintés és a válaszkezelés számára — a fenntartható megközelítés.

Források:

Készen áll az adatai védelmére?

Kezdje el a PII anonimizálását 285+ entitástípuson 48 nyelven.

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.