Adatkezelési tájékoztató - IOA (InOut Assets)

Dokumentum-verzió: 2.0 - Dátum: 2026-10-13 A dokumentum verziója független a szoftver verziójától: egy szövegváltozás akkor is új dokumentum-verzió, ha a program nem változott.

1. Ki kezeli az adatokat, és milyen szerepben

Két különböző adatkezelés fut egymás mellett, és ezt fontos elöl kimondani, mert a jogaid attól függenek, melyikről van szó.

A B) esetben az üzemeltető adatfeldolgozó, nem adatkezelő: az előfizető utasítására tárol és kezel. Ha a saját adataidról szeretnél tájékoztatást vagy törlést a B) körben, az előfizető szervezethez fordulj; az üzemeltető az ő utasítására járhat el. A részleteket az Adatfeldolgozási feltételek (GDPR 28. cikk) tartalmazzák.

Üzemeltető:

• Név: ZeroTime Services Kft.
• Székhely: 1037 Budapest, Montevideo utca 9.
• Cégjegyzékszám: 01-09-454083
• Kapcsolat adatvédelmi ügyben: info@zerotimeservices.com
• Adatvédelmi tisztviselő: nincs kijelölve (LEGAL_DPO). Az üzemeltető megítélése szerint a GDPR 37. cikk (1) bekezdése szerinti kötelező esetek egyike sem áll fenn. Adatvédelmi ügyben a fenti kapcsolattartási címen lehet az üzemeltetőhöz fordulni.

2. Milyen adatot kezelünk - tételesen, a rendszer mezői szerint

Az alábbi felsorolás nem sablon: minden sor mögött egy valódi adatbázis-mező áll.

2.1 Fiók-adatok (A) kör, adatkezelő az üzemeltető)

2.2 A bérlő nyilvántartásában kezelt adatok (B) kör, adatkezelő az előfizető)

3. Mennyi ideig őrizzük - ezt olvasd el figyelmesen

Ami megőrzési idő alapján automatikusan törlődik:

Ami NEM törlődik megőrzési idő alapján:

Ezt a két sort külön olvasd el, mert nem ugyanazt mondják.

Az audit-napló megőrzése rögzítetten korlátlan: ütemezett törlés nincs, és a bérlő sem tudja bekapcsolni. Az üzemeltetőnél létezik egy kézzel futtatható naplóritkító parancs (tenancy:audit-prune), de az szervezetenként a napló megőrzési beállítását olvassa, és mivel ez rögzítetten korlátlan, egyetlen bejegyzést sem töröl: szervezetenként kiírja, hogy 0 sort törölt, és miért. Ütemezve nincs. Ennek a megőrzésnek az oka az, hogy a napló a vagyonátadás bizonyítéka (ki vette át, mikor, milyen állapotban) és a biztonsági események nyoma; egy olyan napló, aminek a hosszát utólag rövidíteni lehet, pontosan azt veszíti el, amiért létezik. A GDPR 5. cikk (1) e) pontja szerinti tárolás-korlátozást ez nem sérti, mert a megőrzés ideje nem végtelen, hanem a bérlői jogviszony életéhez kötött: a szervezet törlésekor a bérlői napló is megszűnik, az alább felsorolt kivételekkel.

A jegyzőkönyvekre a felületen látható megőrzési beállítás viszont ma a jövőbeli automatikus törlés kapcsolója, nem egy már működő folyamat leírása. A lomtárra a beállítás akkor hat, ha az üzemeltető a lomtár automatikus törlését bekapcsolta (lásd a fenti táblát).

És egy harmadik eset, amit külön kimondunk, mert a felület mást sugall: a felületen van egy IP-naplókra vonatkozó megőrzési beállítás is, de a bérlő nyilvántartásában nincs olyan adat, amit ez törölhetne. Az egyetlen IP-cím, amit ott tárolunk, a naplóbejegyzés saját mezője, az pedig az audit-naplóval együtt korlátlanul megmarad. Ez a beállítás tehát ma nem egy még be nem kapcsolt törlés kapcsolója, hanem egy olyan vezérlő, aminek nincs tárgya. Nem hagyjuk szó nélkül, mert egy megőrzési mező, ami semmit nem csinál, pontosan úgy néz ki, mint egy ígéret.

Ebből következően:

• a fenti első táblán kívüli adatok addig maradnak meg, amíg az előfizető szervezet vagy az üzemeltető nem törli őket;
• a jegyzőkönyvekre vonatkozó megőrzési beállítás a jövőbeli automatikus törlés kapcsolója, nem egy már működő folyamat leírása;
• ha az előfizető konkrét megőrzési időt vár el, azt kérnie kell, mert magától nem következik be.

Amit ehelyett tudunk mondani, és ami igaz:

Egy dolgot külön kimondunk, mert könnyű félreérteni: egy szervezet törlésekor az adatbázis-sémát töröljük, de a korábban készült mentésekből az adat nem tűnik el azonnal. A mentés naponta készül, és a napi takarítás azt a mentést törli, amelyik 30 napnál régebbi (LEGAL_BACKUP_RETENTION_DAYS=30). Vagyis egy törlés után az adat még legfeljebb 31-32 napig szerepelhet a korábban készült mentésekben, azt követően azokból is eltűnik.

A törlés két útja, mert nem ugyanazt hagyják hátra:

• Üres szervezet (nincs benne eszköz, jegyzőkönyv és feltöltött fájl): az adatbázis-sémája archívum nélkül, azonnal törlődik, a benne lévő személyekkel és naplóval együtt.
• Minden más szervezet: a törlés előtt a teljes séma (a bérlői naplóval együtt) titkosított archívumba kerül az üzemeltető által kezelt szerveren. Az archívumot a szervezet törlésétől számítva a szervezet jegyzőkönyv-megőrzési idejéig, de legalább 1095 napig (3 év) őrizzük, utána véglegesen eltávolítjuk. Ennek a végleges eltávolításnak a nyoma a törlési tanúsítvány (lásd a 7. pontot).

És ami a bérlő törlése után is szándékosan megmarad, mert nem a bérlő nyilvántartása, hanem az üzemeltető sajátja:

• a platform-szintű napló (platform_audit_events): az üzemeltetői műveletek nyoma, és egy ilyen bejegyzésnek pont akkor kell túlélnie a bérlőt, amikor a bérlő megszűnik;
• a belépési események (auth_events): a belépési kísérletek nyoma, e-mail címmel és IP-címmel, 12 hónapig;
• a fiókok (users), lásd fent;
• a belépés-a-bérlő-nevébe nyilvántartás (impersonation_sessions) és a törlési tanúsítványok.

Ezek személyes adatot tartalmaznak (e-mail címet, a belépési eseményeknél IP-címet is), a jogalapjuk a GDPR 6. cikk (1) f) szerinti jogos érdek: az üzemeltetői műveletek és a belépési kísérletek visszakereshetősége. A mentésekre itt is ugyanaz áll, mint fent: ami egyszer mentésbe került, onnan a mentési ciklus leteltével tűnik el, nem a törlés pillanatában.

4. Az aláírásról - és miért NEM különleges adat

A jegyzőkönyvek átvételi aláírását érintőképernyőn rajzolod meg. Amit a rendszer tárol:

• az aláírás képe,
• az aláíró neve,
• az aláírás időpontja,
• a böngésző-azonosító (user agent).

Amit NEM tárol: dinamikai adatot - nyomást, sebességet, gyorsulást, ritmust, tollemelést. Ez a különbség jogi következménnyel jár: a GDPR 4. cikk 14. pontja szerint biometrikus adat az, amit egyedi azonosításra alkalmas technikai eljárással kezelnek. Egy statikus aláíráskép nem ilyen, ezért nem tartozik a GDPR 9. cikke szerinti különleges adatok közé.

Ezt azért mondjuk ki, mert a hallgatás egy ellenőrzésen ellenünk szólna. Ha a rendszer valaha dinamikai adatot kezdene rögzíteni (például aláírás-hitelesítés céljából), az különleges adat lenne, külön jogalappal és adatvédelmi hatásvizsgálattal - és ez a tájékoztató akkor módosul.

Az aláírás jogi súlyáról: ez eIDAS szerinti egyszerű elektronikus aláírás. Bizonyítékként az EU-ban befogadható (910/2014/EU rendelet 25. cikk (1)), de nem egyenértékű a kézzel írt aláírással - az kizárólag a minősített elektronikus aláírásra igaz (25. cikk (2)).

5. Mi a jogalapunk

Érdekmérlegelés a naplóhoz és az IP-címhez, röviden: a jogos érdek az, hogy egy eszköz átvétele és visszaadása utólag megállapítható legyen, és hogy egy illetéktelen belépés felderíthető legyen. Az adatkör ehhez a legszűkebb: ki, mit, mikor, milyen böngészőből és melyik IP-ről. Nem terjed ki tartalom-elemzésre, profilalkotásra, munkahelyi teljesítménymérésre vagy helymeghatározásra. A napló a felületen az arra jogosultak számára látható, és utólag nem módosítható.

6. Ki fér hozzá

• Az előfizető szervezet arra jogosult munkatársai, a szerepkörük szerint.
• Az üzemeltető munkatársai, kizárólag támogatási és hibaelhárítási céllal.
• Belépés a bérlő nevébe (impersonation): az üzemeltető munkatársa a támogatás során beléphet egy bérlő felhasználójának a nevében. Ez külön nyilvántartásba kerül (impersonation_sessions), és a napló a ténylegesen eljáró személyt is rögzíti (acted_on_behalf_of_*). Ez nem rejtett lehetőség, hanem naplózott és visszakereshető.
• Alfeldolgozók: Az IOA jelenleg nem vesz igénybe külső alfeldolgozót. Az alkalmazás, az adatbázis és a mentések (a feltöltött fájloké is) az üzemeltető saját szerverein futnak, és a mentést is az üzemeltető készíti. Az e-mail-küldés az üzemeltető saját levelezőszerveréről történik, a hibagyűjtő is saját telepítés. A szerverek a Dravanet szervertermében állnak, és az internet-hozzáférést is a Dravanet adja; ez elhelyezés és hálózat, az adathoz nem fér hozzá.
• Robotszűrő a regisztrációs űrlapon: Cloudflare Turnstile. A regisztrációs űrlap betölti a Cloudflare robotszűrőjét, ezért a regisztráló IP-címe és böngészőadatai a Cloudflare-hez jutnak, és a rendszer a beküldéskor a Cloudflare-nél ellenőrzi az eredményt. Erre az adatra a Cloudflare saját adatkezelési feltételei is vonatkoznak.
• Feltételes: ha az e-mail-küldés külső levelező-szolgáltatóra kerül, az a szolgáltató alfeldolgozó lesz, és a bérlőket erről előzetesen értesítjük. A számlázó-szolgáltatóval (Számlázz.hu) a rendszer össze tud kapcsolódni, de ma nincs bekötve: a számla kézzel készül. Ha bekötjük, a számla adatai (a vevő neve, címe, adószáma) hozzá kerülnek. A számla kártyás kifizetéséhez a rendszer a Stripe-hoz tud kapcsolódni, de ez sincs ma bekötve. Ha bekötjük, a kártyaadatot a Stripe saját fizetőoldalán kell megadni: a rendszer azt nem látja és nem tárolja, hozzánk a fizetés azonosítója, összege és eredménye kerül vissza. A bekötés előtt ezt a tájékoztatót kiegészítjük.
• Az adatok fizikai helye: Magyarország, a Dravanet szervertermében.
• Adattovábbítás EU-n kívülre (LEGAL_THIRD_COUNTRY): a rendszer adatai (a fiókok, a szervezetek nyilvántartása, a naplók és a mentések) az EGT-n belül, magyar szerveren maradnak. Az egyetlen kivétel a regisztráció robotszűrője: az ott keletkező IP-cím és böngészőadat a Cloudflare-hez kerül (lásd fent).

7. Hogyan védjük

Mért intézkedések (a mérési alap 1. pontja):

• titkosított kapcsolat (HTTPS);
• bérlőnkénti adatbázis-séma (séma-per-bérlő): minden szervezet adata külön adatbázis-sémában áll, és az alkalmazás minden kérésnél csak a bejelentkezett szervezet sémáját teszi elérhetővé. Az elkülönítést az alkalmazás végzi; az adatbázishoz minden szervezet ugyanazzal az adatbázis-szereppel kapcsolódik, tehát jogosultsági szinten az adatbázis nem választja el őket;
• kétlépcsős azonosítás elérhető;
• a titkos beállítások mezőszinten titkosítva tárolódnak, és a naplóban az értékük helyén [redacted] áll. Ez a beállítás-tárolóra (például a levélküldő hozzáférési adataira) és a titkosnak jelölt szabad mezőkre vonatkozik, a jelöletlen szabad mezőkre nem, lásd a 8. pontot;
• változatlan napló: a bejegyzést utólag módosítani nem lehet (az adatbázis elutasítja);
• vírusellenőrzés a feltöltött fájlokon;
• munkamenet-süti HttpOnly beállítással, 12 órás élettartammal;
• törlési tanúsítvány: egy archivált szervezet végleges törlésekor a rendszer rögzíti az archívum lenyomatát és az eltávolítás igazolását, és megtagadja a végleges törlést, ha az archívum eltűnése nincs igazolva. Az üres szervezet (lásd a 3. pontot) archívum nélkül törlődik, ezért arról tanúsítvány sem készül.

8. A szabad mezőkről - felelősségi határ

A rendszer lehetővé teszi, hogy az előfizető saját mezőket definiáljon a személyekhez, a helyekhez és az eszközökhöz (custom_fields). Ezek tartalmát az előfizető határozza meg, az üzemeltető nem korlátozza és nem elemzi.

Amit ezekről a mezőkről tudni kell, és mérésen alapul (2026-09-04, valódi HTTP-úton igazolva): a szabad mezőknek (custom_fields, default_custom_fields) két állapotuk van, és a különbséget az előfizető állítja be, nem az üzemeltető.

• Titkosnak jelölt mező: az érték az adatbázisban titkosítva tárolódik, és az audit-naplóban sem jelenik meg (a mező neve látszik, az érték helyén [redacted] áll).
• Minden más szabad mező (ez az alapértelmezés): az érték titkosítatlanul tárolódik, és az audit-naplóban is megjelenik, az előtte-utána értékkel együtt.

A jelölés nem automatikus, és visszamenőleg nem hat. Jelölés nélkül az érték nyersen áll az adatbázisban is és a naplóban is, ezért minden mentés, adatbázis-kimentés és visszaállítás nyersen viszi. A mező NEVE semmit nem jelent: egy api_token nevű mező jelölés nélkül pontosan ugyanúgy viselkedik, mint bármelyik másik. A 7. pontban említett mezőszintű titkosítás a beállítás-tárolóra és a titkosnak jelölt szabad mezőkre vonatkozik, a jelöletlenekre nem.

Ebből két dolog következik.

Egy: a jelöletlen szabad szöveges mezők nem alkalmasak jelszó, hozzáférési kulcs vagy más titok tárolására. A titkos jelölés csak a mező létrehozásakor adható meg, és csak szöveges mezőnél: egy meglévő mezőt utólag nem lehet titkossá tenni. Ha ilyen érték mégis jelöletlen mezőbe került, új, titkosnak jelölt mezőt kell létrehozni, az értéket abba átvinni, és a régit kiüríteni - a régi érték a naplóban ettől még megmarad.

Kettő: ha ilyen mezőbe különleges adat kerül (egészségügyi adat, szakszervezeti tagság, egyéb 9. cikk szerinti adat), az az előfizető adatkezelése és felelőssége, és az ő oldalán keletkezik többletkötelezettség. A rendszer erre nincs felkészítve, és nem is ajánljuk.

9. Milyen jogaid vannak

Tájékoztatás, hozzáférés, helyesbítés, törlés, korlátozás, adathordozhatóság, tiltakozás (GDPR 15-22. cikk). Hova fordulj:

• fiók-adatok (A) kör): az üzemeltetőhöz, a fenti elérhetőségen;
• a bérlő nyilvántartásában lévő adatok (B) kör): az előfizető szervezethez. Ha hozzánk fordulsz, továbbítjuk, de önállóan nem járhatunk el - az előfizető utasítására dolgozunk.

A törlés korlátja a bérlő nyilvántartásában, ahogy a rendszer ma működik: egy személy, akihez eszközmozgás tartozik (átvett, átadott vagy nála van egy eszköz), nem törölhető; a rendszer a törlést elutasítja; a támogatott út a "kilépett" állapot. Anonimizálás nincs. Ha a személy adatait átírják, a korábbi név, e-mail cím és telefonszám az audit-naplóban megmarad (lásd a 3. pontot). A törlési kérelmet ilyenkor a szervezet ennek tudatában bírálja el.

Panasszal a Nemzeti Adatvédelmi és Információszabadság Hatósághoz fordulhatsz (1055 Budapest, Falk Miksa utca 9-11.; ugyfelszolgalat@naih.hu), illetve bírósághoz.

10. A tájékoztató változása

Minden érdemi változás új dokumentum-verziót kap saját dátummal. A regisztrációkor elfogadott konkrét verziót a rendszer rögzíti, tehát utólag megállapítható, ki melyik szöveget fogadta el.

Változásjegyzék