A DPIA (Data Protection Impact Assessment — adatvédelmi hatásvizsgálat) a személyes adatok feldolgozásának az érintett személyek jogaira és szabadságaira gyakorolt hatásának formális értékelése a GDPR 35. cikke szerint. ERP/CRM rendszer bevezetésekor mindig kötelező, ha a feldolgozás valószínűleg magas kockázattal jár — jellemzően alkalmazottak szisztematikus monitorozásakor, különleges kategóriájú adatok feldolgozásakor, automatizált döntéshozatalnál (AI pontozás) vagy nagy adathalmazok kombinálásánál. A standard DPIA 8 szakaszból áll és elkészítése 2–5 nap munkát vesz igénybe.

Ez a cikk a felhő ERP biztonság és megfelelés sorozat részét képezi. Elmagyarázza, mikor kötelező a DPIA ERP/CRM-hez, hogyan kell strukturálni Modulario bevezetésnél, 8 lépéses sablont kínál és felhívja a figyelmet a gyakori hibákra.

Mi a DPIA és miért fontos

A DPIA az adatvédelem területén a proaktív kockázatkezelés eszköze. Célja nem a bürokrácia, hanem:

  1. A kockázatok azonosítása azelőtt, mielőtt a felügyeleti hatóság vagy az érintett azonosítja azokat.
  2. Az elgondolás dokumentálása — az elszámoltathatóság igazolása a GDPR 5. cikk (2) bekezdése szerint.
  3. Kockázatcsökkentő intézkedések javaslása.
  4. Konzultáció a hatósággal (Magyarországon a NAIH — Nemzeti Adatvédelmi és Információszabadság Hatóság), ha a kockázat nem csökkenthető.

DPIA nélkül ott, ahol kötelező, legfeljebb 20 millió EUR vagy a globális forgalom 4%-ának megfelelő bírság fenyeget. Magyarországon a NAIH 2024-ben bírságot szabott ki egy webáruházra az ügyfélprofilozáshoz hiányzó DPIA miatt.

Mikor kötelező a DPIA ERP/CRM-hez

Három kritérium a GDPR 35. cikke szerint

A DPIA kötelező, ha a feldolgozás valószínűleg magas kockázatot jelent a természetes személyek jogaira és szabadságaira. Kritériumok:

  1. Személyes szempontok szisztematikus és kiterjedt értékelése profilalkotással együtt, amelynek jogi hatása van vagy hasonlóan jelentős mértékben érinti a személyt (pl. AI pontozás jelöltekre a HR modulban).
  2. Különleges kategóriájú adatok feldolgozása a 9. cikk szerint (egészségügyi adatok, biometria, etnikai származás, politikai vélemények) nagy léptékben.
  3. Nyilvánosan hozzáférhető terület szisztematikus, nagy léptékű megfigyelése (CCTV, személyazonosítással rendelkező IoT érzékelők).

Az EDPB és a NAIH listái

Az EDPB és a NAIH kiadtak feldolgozási típusok listáját, ahol a DPIA kötelező. ERP/CRM szempontjából különösen relevánsak:

  • Automatizált értékeléssel rendelkező HR rendszerek (teljesítménypont-rendszer, prediktív értékelés)
  • Marketingcélzáshoz szükséges kiterjedt ügyfelprofilozással rendelkező CRM
  • GPS-alapú valós idejű alkalmazottkövetéssel rendelkező helyszíni szolgáltatáskövetés
  • Biometrikus jelenléti rendszerek (ujjlenyomat, arc)
  • AI modulok hitelpontozáshoz, csalásdetektáláshoz, ügyfélszolgálat automatizáláshoz
  • Személyazonosítással rendelkező IoT integrációk (okos kártyák, RFID jelenléti nyilvántartás)
  • Harmadik felekkel kombinált nagy ügyfél-adathalmazok (adatgazdagítás)

Gyakorlati döntési fa

KérdésIgenNem
Nagy léptékben feldolgoz különleges kategóriájú adatokat (egészség, biometria)?DPIA kötelezőFolytatás
Jogi hatással járó automatizált döntéshozatalt végez (HR pontozás, hitelpontozás)?DPIA kötelezőFolytatás
Monitorozza az alkalmazottakat (GPS, billentyűzetfigyelés, videó)?DPIA kötelezőFolytatás
100 000-nél több érintettet (ügyfeleket, alkalmazottakat) dolgoz fel?DPIA ajánlottFolytatás
Innovatív technológia (AI, IoT, biometria)?DPIA ajánlottDPIA nem kötelező

Tipp: Még ha a DPIA nem is kötelező, a kockázatelemzés mindig ajánlott és segít egy jövőbeli audit során. A Modulario bevezetésnél elvégezhetjük Önnek egy csökkentett DPIA-light verzióban.

DPIA 8 lépésben: sablon Modulario bevezetéshez

Standard struktúra a GDPR 35. cikk (7) bekezdése + EDPB legjobb gyakorlata szerint:

1. lépés: Feldolgozás szisztematikus leírása

Írja le:

  • Feldolgozás célja (pl. „alkalmazottak nyilvántartása, bérszámfejtés, jelenléti nyilvántartás, teljesítményértékelés”)
  • Jogalap (GDPR 6. cikk + esetleg 9. cikk különleges kategóriáknál)
  • Érintett személyek kategóriái (alkalmazottak, ügyfelek, szállítók)
  • Adatkategóriák (azonosítási, kapcsolattartási, gazdasági, helymeghatározási, biometrikus)
  • Címzettjei (belső felhasználók, külső — könyvelő, adóhivatal, bank, alfeldolgozók)
  • Megőrzési idők (kategóriánként)
  • Határon átnyúló adattovábbítás (EU igen/nem, harmadik országok)

Modulario sajátosságai: elsődleges adatok az EU-ban (Frankfurt + Prága), az EU-n kívülre nem kerülnek adatok, alfeldolgozók csak EU-beli natívak vagy megfelelő garanciákkal.

2. lépés: Szükségesség és arányosság értékelése

Kérdések:

  • Szükséges-e a feldolgozás a cél eléréséhez?
  • Az adatmennyiség arányos-e a célhoz (adatminimalizálás)?
  • Van-e kevésbé beavatkozó alternatíva?
  • A megőrzési idő a lehető legrövidebb-e?
  • Az érintetteket átláthatóan tájékoztatták-e?

Példa: Jelenléti nyilvántartáshoz szükséges a név, belépőkártya és érkezési/távozási időpont. A biometria nem szükséges — használhat chipet vagy PIN-t. Ha biometriát alkalmaz, indokolni kell (pl. raktár fizikai biztonsága) és kifejezett hozzájárulást kell szerezni.

3. lépés: Kockázatok azonosítása

Minden feldolgozási kategóriánál gondoljon:

  • Fenyegetések: adatszivárgás (belső, külső támadás), illetéktelen hozzáférés, adatmódosítás, adatvesztés.
  • Sebezhetőségek: gyenge jelszavak, nem frissített szoftver, nem megfelelő RBAC, hiányzó titkosítás, szállítói kockázat.
  • Hatások: érintett személyek pénzügyi kára, reputációs kár, diszkrimináció, személyazonosság-lopás, fizikai biztonság.

Valószínűség × hatás alapján alacsony / közepes / magas kockázatként osztályozza.

4. lépés: Kockázatcsökkentő intézkedések

Technikai:

  • Titkosítás tároláskor (AES-256) és átvitel közben (TLS 1.3) — Modulario alapértelmezés.
  • MFA adminisztrátoroknak és érzékeny hozzáférésekhez — Modulario TOTP/WebAuthn/SAML-támogatás.
  • Szerepkör-alapú hozzáférés-vezérlés least-privilege elvvel — Modulario Emberek modul.
  • Audit napló forenzikus képességhez — Modulario natív.
  • Automatizált megőrzési szabályzatok a határidő utáni törléssel — Modulario attribútumonként konfigurálható.
  • Álnevesítés / anonimizálás ahol lehetséges.
  • Biztonsági mentés és helyreállítás teszteléssel.

Szervezeti:

  • Alkalmazotti képzés (évente).
  • Szállítói átvilágítás (DPA minden adatfeldolgozóval).
  • Incidenskezelési terv 72 órás GDPR-értesítéssel.
  • DSAR folyamat 30 napos határidővel.
  • Belső audit az ellenőrzésekről min. évente 1-szer.

5. lépés: Konzultáció az érintett felekkel (ahol szükséges)

Ha a kockázat még mindig magas, a GDPR javasolja:

  • Konzultáció az érintettekkel (pl. munkavállalói képviselőkön, felméréseken keresztül).
  • Konzultáció a DPO-val (ha van).
  • Konzultáció a hatósággal (NAIH), ha intézkedések után sem elfogadható a kockázat.

6. lépés: Jóváhagyás és dokumentálás

A DPIA-nak:

  • Írásos kell lennie és a felelős személy aláírásával.
  • Dátumozva kell lennie felülvizsgálati tervvel (jellemzően évente 1-szer vagy feldolgozás változásakor).
  • Tárolt kell legyen a GDPR-dokumentáció részeként.

7. lépés: Intézkedések végrehajtása

Tervezze meg:

  • Minden intézkedés tulajdonosát.
  • Végrehajtás határidejét.
  • Ellenőrzés módját (teszt, audit, monitorozás).

Modulario bevezetésnél sok technikai intézkedés már fut — az ügyfél oldalán szervezeti beállítás és folyamatok maradnak.

8. lépés: Monitorozás és felülvizsgálat

A DPIA nem egyszeri dokumentum. Felülvizsgálat szükséges:

  • Feldolgozás változásakor (új modul, új alfeldolgozó, cél változása).
  • Jogszabályváltozáskor (pl. AI Act, EDPB útmutatók).
  • Személyes adatokat érintő incidensnél.
  • Rendszeresen évente 1-szer a GDPR-audit részeként.

Gyakorlati példa: DPIA a Modulario HR modulhoz

Forgatókönyv: Közepes gyártócég (120 alkalmazott) bevezeti a Modulario Emberek modult HR-nyilvántartáshoz, bérszámfejtéshez és jelenléti nyilvántartáshoz chipkártyákkal.

Rövid DPIA:

SzakaszTartalom
CélSzemélyzeti nyilvántartás, bérszámfejtés, jelenléti nyilvántartás, szabadságkezelés
Jogalap6. cikk (1)(b) — szerződés (munkaviszony) + 6. cikk (1)(c) — törvényes kötelezettség
Érintett személyek120 alkalmazott
AdatkategóriákAzonosítási, kapcsolattartási, bérszámfejtési, helymeghatározási (chip)
Különleges kategóriákNincs (a chip nem biometria)
CímzettjeiSzemélyzeti osztály, könyvelő, NAV, bankok
AlfeldolgozókModulario (EU), AWS Frankfurt (DE), biztonságos e-mail relay (EU)
Megőrzési időkBérszámfejtési lapok 50 év, személyzeti dosszié 50 év, jelenléti nyilvántartás 5 év
Határon átnyúló adattovábbításNincs az EU-n kívülre
KockázatokBérszámfejtési adatok szivárgása (magas hatás, alacsony valószínűség intézkedések után), személyzeti adatokhoz illetéktelen hozzáférés (közepes hatás, alacsony valószínűség)
Technikai intézkedésekModulario alapértelmezés — titkosítás, MFA, audit napló, RBAC, EU-s hosting, ISO 27001
Szervezeti intézkedésekTiszta asztal szabályzat, HR osztály képzése, DSAR folyamat, megőrzési szabályzat
Maradék kockázatAlacsony
KövetkeztetésA DPIA nem azonosított kezelhetetlenül magas kockázatokat. Hatósági konzultáció nem szükséges.

A teljes DPIA ehhez a forgatókönyvhöz kb. 8 oldal, és 2–3 nap alatt elkészíthető. A Modulario sablont biztosít az ügyfeleknek, ahol az intézkedések nagy része előre kitöltött.

A DPIA leggyakoribb hibái

  1. „Egyszer kitöltöttük a táblázatot és kész.” A DPIA élő dokumentum. Egy év utáni felülvizsgálat nélkül értéktelen.
  2. Túl általános leírások. „Személyes adatokat dolgozunk fel üzleti célból” nem leírás. Pontosnak kell lenni — kategóriák, időtartam, címzettjei.
  3. Alfeldolgozók figyelmen kívül hagyása. A szállító (AWS, Sentry, e-mail provider) a kockázatelemzés része. DPA nélkülük hiányosság van.
  4. Nincs hozzáférési jog tervezés. Ha DSAR kérelem érkezik, 30 napon belül képes exportálni egy személy összes adatát? Tesztelje.
  5. DPIA technikai validálás nélkül. Az „adatainkat titkosítjuk” intézkedéseket az IT-nek kell megerősíteni, nem csak az ügyvédnek. Ha az adatbázis valójában nincs titkosítva, a DPIA félrevezető.
  6. Összefoglaló nem kerül közzétételre. Magasabb kockázatnál az EDPB javasolja a DPIA összefoglalójának közzétételét az átláthatóság érdekében.
  7. DPIA és ROPA összekeverése. Az adatkezelési tevékenységek nyilvántartása (30. cikk) más dokumentum, mint a DPIA (35. cikk). Mindkettőre szüksége van.

Modulario sablon és támogatás

A Modulario ügyfelei számára biztosítjuk:

  • DPIA sablont tipikus use-case-ekhez (HR, raktár, számlázás, CRM, helyszíni szolgáltatás, IoT).
  • Előre kitöltött technikai intézkedéseket a Modulario architektúrájának megfelelően (EU-s hosting, ISO 27001, audit napló, titkosítás, MFA).
  • Alfeldolgozó listát aktuális DPA hivatkozásokkal.
  • Konzultációt összetett bevezetéseknél (AI modulok, IoT, biometria).

Csak igényelje az ingyenes konzultációt.

Kapcsolódó témák: felhő ERP biztonsági pillér, ISO 27001 KKV-knak, NIS2 a gyakorlatban.

Gyakran ismételt kérdések

El kell végeznem a DPIA-t a standard könyvelési/számlázási modulhoz? A standard B2B számlázáshoz vagy egy rendes vállalat könyveléséhez a DPIA általában nem kötelező — a feldolgozás törvényes kötelezettség teljesítéséhez szükséges (GDPR 6. cikk (1)(c)), a terjedelem arányos és különleges kategóriájú adatokat nem dolgoznak fel. Ajánlunk azonban egy rövid kockázatelemzést (2–3 oldal) a GDPR-dokumentáció részeként.

Használhatok internetes DPIA-sablont, vagy nulláról kell kezdenem? A sablonok jó kiindulópontok, de a saját konkrét forgatókönyvhöz kell igazítani. A vállalata, adatai és szállítói sajátosságai nélküli általános DPIA nem elégíti ki a felügyeleti hatóságot. A Modulario sablonja tipikus bevezetésekhez igazított és konkrét technikai intézkedéseket tartalmaz, így felgyorsítja a munkát.

Ki végzi el a DPIA-t a vállalatnál? A felelősség az adatkezelőnél van, jellemzően az adatvédelmi tisztviselőn (DPO) vagy megfelelési tisztviselőn keresztül. DPO nélküli KKV-knál ezt egy kombináció végzi: üzleti tulajdonos (feldolgozás leírása), IT/CISO (technikai intézkedések), ügyvéd (jogalap és kockázatok). Külső tanácsadó összetett esetekhez (AI, biometria, nagy adathalmazok) ajánlott.

Mi van, ha a DPIA után azt találom, hogy a kockázat magas és nem tudom csökkenteni? Akkor konzultálnia kell a felügyeleti hatósággal (Magyarországon a NAIH-hel) a GDPR 36. cikke szerint. A hatóságnak 8 hete van a válaszra (6 héttel meghosszabbítható összetett esetekben). A konzultáció nem jelent tiltást — a hatóság további intézkedéseket javasolhat. Magas maradék kockázat esetén konzultáció nélkül GDPR-sértés.