Érdekmérlegelési teszt (LIA)

A jelen dokumentum a természetes személyeknek a személyes adatok kezelése tekintetében történő védelméről szóló (EU) 2016/679 rendelet (GDPR) 6. cikk (1) bekezdés f) pontja szerinti jogalap alkalmazhatóságát adatkezelési műveletenként vizsgáló, dokumentált érdekmérlegelési teszt. Státusz: HATÁLYOS 2026. szeptember 24. napjától — a 21. fejezet szerinti production implementációs kapu teljesült. A jogszabályi és tényállási időállapot: 2026. szeptember 24.

1. A dokumentum célja, státusza és módszertana

1.1. A dokumentum célja

A RENEXUS SYSTEMS Kft. (székhely: 8000 Székesfehérvár, Mikszáth Kálmán utca 13.; cégjegyzékszám: 07-09-037642; adószám: 33067388-2-07; a továbbiakban: RENEXUS) a RENEXUS elektronikus szakági ajánlatkérési rendszer működtetése során nyilvánosan elérhető szakmai és üzleti forrásokból természetes személyekhez köthető adatokat kezel. A jelen dokumentum a GDPR 6. cikk (1) bekezdés f) pontjának alkalmazhatóságát adatkezelési műveletenként vizsgálja.

A jelen LIA nem egyetlen, általános „tender-meghívási jogos érdeket” tételez, hanem külön vizsgálja legalább a forráslekérdezést, a discovery index létrehozását és fenntartását, a provenance-kezelést, az identitáskezelést és deduplikációt, a communication vaultban történő e-mail-tárolást, az objektív relevanciaszűrést, az emberi kiválasztást, a piszkozat- és küldési folyamatot, a küldés előtti újraellenőrzést, a JIT kontaktfeloldást, a konkrét tender-meghívás kiküldését, az esemény- és hozzáférési auditot, valamint a globális suppression rendszert.

1.2. A LIA v2 hatálybalépési feltétele

A jelen szöveg a RENEXUS 2026. szeptember 24-én stagingen validált célállapotára készült. E célállapot fő elemei:

• a discovery index és a communication vault szétválasztása;
• nyers e-mail kizárólag a vaultban, JIT feloldással;
• telefonszám-kezelés teljes megszüntetése;
• pontozás és természetes személyek közötti rangsorolás teljes megszüntetése;
• kizárólag objektív szakmai és földrajzi relevanciaszűrés;
• emberi címzett-kiválasztás;
• egy címzett + egy tender = egy cold tender-meghívó, releváns munkarészek aggregálásával;
• változatlan tender duplikált újraküldésének blokkolása;
• minden cold tender-meghívóban rétegzett GDPR 14. cikk szerinti tájékoztatás és jól látható tiltakozási lehetőség;
• globális, identitásalapú suppression;
• küldés előtti fail-closed újraellenőrzés;
• source-date alapú contact-freshness;
• retention-infrastruktúra első körben kizárólag report/dry-run módban.

A jelen LIA nem léphet hatályba és nem tehető közzé hatályos dokumentumként mindaddig, amíg a fenti célállapot production rolloutja és az ahhoz előírt QA sikeresen le nem zárult. A dokumentum kizárólag a jelen dokumentumban meghatározott production implementációs kapu teljesülését követően lép hatályba. A kaput a 21. fejezet határozza meg; a kapu 2026. szeptember 24. napján teljesült, a v2.0 ettől a naptól hatályos.

1.3. Időállapot és visszamenőleges hatály kizárása

A jogszabályi és tényállási időállapot 2026. szeptember 24. A dokumentum nem minősíti visszamenőleg jogszerűnek a korábbi adatkezelési gyakorlatot. Különösen nem orvosolja visszamenőleg:

• a korábbi meghívók GDPR 14. cikk szerinti egyedi tájékoztatási hiányát;
• a korábbi marketingjellegű vagy vegyes célú sablonelemeket;
• a korábbi telefonszám-tárolást;
• a korábbi pontozást és rangsorolást;
• a történeti legacy PII határozatlan megőrzését.

E kérdések a DPIA-ban és a külön historical-remediation tervben maradványkockázatként kezelendők.

1.4. Módszertan

A jogos érdek vizsgálata minden műveletnél három egymásra épülő kérdésből áll:

1. 1. Célteszt: fennáll-e jogszerű, kellően konkrét, valós és aktuális jogos érdek?
2. 2. Szükségességi teszt: az adott adatkezelési művelet szükséges-e e cél eléréséhez, és van-e ugyanolyan hatékony, ésszerűen rendelkezésre álló, az érintett jogait kevésbé korlátozó alternatíva?
3. 3. Érdekmérlegelés: a RENEXUS és adott esetben harmadik fél jogos érdekeivel szemben elsőbbséget élveznek-e az érintett érdekei, alapvető jogai vagy szabadságai?

A vizsgálatban csak ténylegesen implementált vagy a hatálybalépési kapuval kötelezően együtt élesítendő garancia vehető figyelembe. A GDPR által eleve kötelező intézkedések teljesítése önmagában nem tekintendő többlet-mitigációnak.

2. Szerepek és az adatkezelési lánc

2.1. RENEXUS önálló adatkezelői szakasza

A RENEXUS önálló adatkezelőként határozza meg a discovery rendszer általános célját és lényeges eszközeit, különösen:

• a felhasznált forráscsaládokat;
• az indexben kezelt adatkategóriákat;
• a provenance szerkezetét;
• a stabil subject-identity modellt;
• a communication vault működését és hozzáférési rendjét;
• a globális suppression szabályait;
• az objektív relevanciaszűrés általános logikáját;
• a biztonsági és elszámoltathatósági naplókat;
• az index- és vault-szintű megőrzési szabályokat.

A discovery index és a vault nem egyetlen ajánlatkérő utasítására és nem kizárólag egyetlen ajánlatkérő részére jön létre, ezért e műveletekben a RENEXUS nem adatfeldolgozó.

2.2. Konkrét tenderhez kapcsolódó közös szakasz

A rendszer alapértelmezett joint módjában az adott tenderhez kapcsolódó releváns jelöltkör kialakítása, az ajánlatkérő általi címzett-kiválasztás és a meghívási folyamat olyan egymásra épülő döntéseket tartalmaz, amelyekben:

• az ajánlatkérő határozza meg a beszerzési célt, a tendert, a munkarészt és a szakmai feltételeket;
• a RENEXUS biztosítja a discovery indexet, a szűrési infrastruktúrát, a kommunikációs rendszert, a suppressiont, az újraellenőrzést és a sablon-technológiát;
• a konkrét címzetteket az ajánlatkérő emberi döntéssel választja ki;
• legalább 100 címzett esetén a rendszer kifejezett megerősítést kér és auditálja azt;
• a kiküldéshez a RENEXUS technikai csatornája használható, a levélben az ajánlatkérő kiléte és a RENEXUS platformszerepe egyértelműen elkülönül.

E szakasz a GDPR 26. cikke szerinti közös adatkezelésnek minősülhet. A közös adatkezelés részletes felelősségmegosztását külön 26. cikk szerinti megállapodásban kell rögzíteni, és annak lényegét az érintettek számára hozzáférhetővé kell tenni.

2.3. Adatfeldolgozói szakaszok

A RENEXUS adatfeldolgozói szerepe különösen akkor állhat fenn, amikor:

• az ajánlatkérő saját, kézzel vagy fájlból feltöltött beszállítói listáját kezeli, és az adat nem olvad be a RENEXUS általános discovery indexébe;
• későbbi processor mode esetén az ajánlatkérő maga határozza meg és hagyja jóvá a címzettlistát, a sablont, a feladói identitást és a megőrzést, a RENEXUS pedig kizárólag az írásbeli utasítás végrehajtását végzi.

E műveletekhez GDPR 28. cikk szerinti adatfeldolgozói megállapodás szükséges.

2.4. Állami és önkormányzati ajánlatkérő

A jelen LIA a RENEXUS saját, GDPR 6. cikk (1) f) szerinti adatkezelését vizsgálja. Nem szolgáltat jogalapot közhatalmi vagy közfeladatot ellátó ajánlatkérő olyan adatkezelésére, amelyet saját közfeladata ellátása körében végez. Állami vagy önkormányzati pilot előtt külön controller-role memorandum, DPIA és az ajánlatkérő saját jogalapjának meghatározása szükséges; az ajánlatkérő oldalán különösen a GDPR 6. cikk (1) e) pontja merülhet fel, ha az alkalmazhatóság jogszabályi feltételei fennállnak.

3. Az adatkezelés architektúrája és adatkategóriái

3.1. Discovery index

A discovery index célja, hogy a szakmai vagy vállalkozási tevékenység alapján objektíven kereshetővé tegye a potenciálisan releváns gazdasági szereplőket és szakembereket. A tartós discovery rekord a célállapotban nem tartalmaz nyers e-mail-címet vagy telefonszámot.

A kezelhető adatkategóriák különösen:

• név vagy cégnév;
• kamarai azonosító, kamara;
• szakmai jogosultság és annak érvényessége;
• szakág vagy tevékenységi kategória;
• település, régió vagy más szakmailag indokolható földrajzi adat;
• vállalkozási domain és adószám, ha releváns;
• forrás és forrásállapot;
• forrás megfigyelési/gyűjtési ideje;
• aktív/megjeleníthető státusz.

3.2. Communication vault

A személyhez köthető cold e-mail-cím a discovery indextől elkülönített communication vaultban tárolódik. A célállapotban telefonszám nem kerül a vaultba és a tender-meghívási rendszer egyetlen rétege sem kezeli azt.

A nyers e-mail-címhez való hozzáférés:

• célhoz kötött resolveren keresztül történik;
• kizárólag meghatározott purpose értékekkel engedélyezett;
• naplózott;
• a cold tender-meghívásnál csak közvetlenül a tényleges küldés előtt történik;
• a discovery frontendnek és a normál keresési API-nak a nyers e-mail-cím nem kerül átadásra.

3.3. Provenance

A rendszer rekord- és mezőszintű provenance adatokat kezel annak érdekében, hogy visszakövethető legyen:

• a forráscsalád;
• ahol rendelkezésre áll, a forrásazonosító vagy URL;
• a gyűjtés/észlelés időpontja vagy intervalluma;
• a forrásállapot;
• az adatok frissességi horgonya.

A provenance célja az elszámoltathatóság, a GDPR 14. cikk szerinti forrásközlés, a pontosság és a joggyakorlás támogatása.

3.4. Suppression

A suppression-rendszer külön kezeli legalább:

• az érintett tiltakozását / „ne keressenek többet” nyilatkozatát;
• a marketing-only tiltást;
• a kézbesíthetetlen vagy hibás contact címszintű blokkolását;
• a bizonytalan, kézi felülvizsgálatra szoruló eseteket.

Az érintett tiltakozásához kötött alanyszintű suppression forrásfüggetlen: új adatforrás vagy új e-mail-cím önmagában nem aktiválhatja újra a cold tender-outreachot.

4. Adatforrások és forráskockázatok

4.1. Kamarai jogosultsági adatok

A kamarai szakmagyakorlási nyilvántartások jogi hátterét különösen a magyar építészetről szóló 2023. évi C. törvény (Méptv.) és a 266/2013. (VII. 11.) Korm. rendelet adja. A Méptv. 207. §-a és a Korm. rendelet 30. §-a alapján a szakmai nyilvántartások egyes adatai nyilvánosan megismerhetők; az e-mail-cím és a telefonszám azonban nem azonos jogi helyzetű a kötelezően nyilvános szakmai jogosultsági adatokkal.

A RENEXUS a kamarai nyilvánosságot nem tekinti önmagában adatkezelési jogalapnak és nem tekinti automatikus újrafelhasználási engedélynek. A RENEXUS adatkezelésének jogalapját e LIA vizsgálja.

A korábbi MMK/MÉK tömeges adatkinyerés adatbázisjogi és forráshasználati kockázata külön residual risk. A célállapot nem tartalmaz új, periodikus teljes kamarai scrapinget. A FULL_REGISTRY_REFRESH teljes registry-frissítésre letiltott. A meglévő snapshot és provenance kezelése nem jelenti azt, hogy a RENEXUS kamarai licenc vagy engedély meglétét állítaná.

4.2. MMK

A 2026. májusi MMK adatgyűjtés során a szakmai jogosultsági és kapcsolati adatok nyilvános keresőfelületről kerültek feldolgozásra. A forrásoldalon kifejezett scraping-felhasználási feltétel nem került igazolásra, de ez önmagában nem keletkeztet újrafelhasználási jogosultságot. A korábbi gyűjtési módszer skálája és technikai jellege a DPIA-ban külön kockázatként kezelendő.

4.3. MÉK / MEKON

A MÉK/MEKON forrásnál dokumentált, hogy a tag egyes elérhetőségeinek nyilvánossága kamarai nyilatkozathoz kötődhetett. Ugyanakkor a RENEXUS nem tekinti igazoltnak, hogy ez harmadik fél részére korlátlan adatbázis-újrafelhasználási jogot biztosít. A MÉK-portál jogi nyilatkozatának a tényleges MEKON-forrásra való kiterjedése nem lezárt kérdés; ez residual risk és külön forrásjogi vizsgálat tárgya.

4.4. REKORE

A REKORE-adatok nyilvános szakmai taglistához köthetők, de a közzétételi és újrafelhasználási alap nem teljes körűen igazolt. A forrás státusza ezért partial. Új automatikus full REKORE-import nem része a célállapotnak.

4.5. Vállalkozási weboldalak

A vállalkozási honlapról kezelt adat kizárólag szakmai/üzleti kapcsolatfelvételi célhoz kapcsolódó adat lehet. A forrás technikai vagy szerződéses korlátozásainak megkerülése nem megengedett. A magánjellegű, nem szakmai kapcsolatfelvételre közzétett címek célzott gyűjtése nem része a RENEXUS céljának.

5. Jogos érdekek azonosítása

A RENEXUS jogos érdekei a következők:

1. 1. Szakmailag releváns ajánlattevői kör feltárása: a RENEXUS alapvető szolgáltatási értéke, hogy az ajánlatkérők a konkrét beszerzési igényhez megfelelő szakmai kört érhessenek el.
2. 2. Konkrét beszerzési lehetőség közvetítése: a megkeresés elsődleges célja nem a RENEXUS szolgáltatásának értékesítése, hanem konkrét ajánlatkérő konkrét beszerzési igényének közvetítése.
3. 3. A platform megbízható és jogszerű működtetése: provenance, deduplikáció, suppression, audit, security és send-time revalidation fenntartása.
4. 4. Pontosság és címzetti terhelés csökkentése: elavult vagy irreleváns címzett kiszűrése, ugyanazon tenderen belüli több munkarész összevonása, változatlan tender duplikált újraküldésének megakadályozása.

A magánszektorbeli ajánlatkérőnek emellett saját jogos érdeke lehet a releváns ajánlattevők elérése és a verseny erősítése. Közös adatkezelési szakaszban minden adatkezelőnek saját jogalapját külön kell igazolnia.

6. Műveletenkénti érdekmérlegelés

6.1. Nyilvános szakmai forrás lekérése — jogosultsági és discovery-adat

Cél: szakmailag kereshető discovery index létrehozása.

Szükségesség: a szakmai jogosultság és tevékenységi relevancia előzetes ismerete nélkül a célzott tender-meghívás vagy lényegesen pontatlanabb, vagy indokolatlanul széles címzetti kört érne el. A kizárólag regisztrált felhasználói körre korlátozás a szolgáltatás discovery-funkcióját lényegében megszüntetné.

Érintetti hatás: a nyilvános szakmai jogosultsági adatok indexelése a forrás szerinti egyszeri megismeréshez képest többletbeavatkozás, mert strukturált és kereshető adatállomány keletkezik. E hatást mérsékli az adatkör szűkítése, a zárt hozzáférés, a provenance és az, hogy a discovery index nyers kontaktadatot nem tartalmaz.

Eredmény: FELTÉTELESEN MEGFELELŐ, feltéve, hogy nincs új periodikus full registry scraping; az adatforrások provenance-a fennmarad; a retention és forrásfrissesség ténylegesen alkalmazásra kerül; a source/database-right residual risket a DPIA dokumentálja.

6.2. Kamarai és webes e-mail-adat gyűjtése / communication vaultba helyezése

Cél: konkrét, szakmailag releváns tender-meghívás kézbesíthetősége.

Szükségesség: e-mailes megkereséshez használható elérhetőség szükséges. A RENEXUS az e-mailt nem tartja a discovery master-recordban, és azt csak JIT módon oldja fel a tényleges küldéshez.

Alternatívák: kizárólag regisztrált felhasználók használata a discovery-modellt kiüresítené; minden egyes tenderkor új, teljes körű manuális contact-felderítés aránytalan és pontatlanságot növelő alternatíva lenne. A contact tartós master-adatként tárolása viszont nem szükséges, ezért a vault-architektúra kötelező safeguard.

Érintetti hatás: személyhez kötött céges/szakmai e-mail cím kezelése tényleges adatvédelmi beavatkozás, különösen akkor, ha a közzététel eredeti célja nem kifejezetten harmadik fél tender-meghívása volt.

Eredmény: FELTÉTELESEN MEGFELELŐ kizárólag a következő garanciákkal: vault-only nyers contact; JIT feloldás; access log; source-date; Art. 14 tájékoztatás; globális tiltakozás; retention. A forráshasználati jogkérdés ettől elkülönült residual risk.

6.3. Telefonszám gyűjtése és tárolása

A tender-meghívási rendszer a célállapotban telefonszámot nem használ.

Eredmény: NEM SZÜKSÉGES / NEM IGAZOLHATÓ. A production rollout feltétele a telefonadatok aktív rendszerből való teljes kivezetése és az új import tiltása.

6.4. Discovery index tartós fenntartása

Cél: ne kelljen minden tendernél a teljes szakmai forráskört újra feldolgozni; a releváns szakmai identitás és jogosultság kereshető maradjon.

Szükségesség: tartós, de felülvizsgált index a szolgáltatás működéséhez szükséges; korlátlan és határozatlan tárolás azonban nem.

Eredmény: FELTÉTELESEN MEGFELELŐ, feltéve, hogy a retention és review policy ténylegesen érvényesül, a forrásból eltűnt vagy tartósan elavult rekord nem marad határozatlanul aktív.

6.5. Provenance

Cél: elszámoltathatóság, forrásközlés, pontosság, joggyakorlás és audit.

Szükségesség: a nem az érintettől gyűjtött adatok esetén a forrás rekonstruálhatósága alapvető megfelelési követelmény. A provenance-adat maga csak a szükséges mértékben tartalmazhat személyes adatot.

Eredmény: MEGFELELŐ.

6.6. Stabil identity és deduplikáció

Cél: ugyanazon személy több forrásból érkező rekordjainak téves többszörözésének csökkentése, a globális tiltakozás érvényesítése és az újragyűjtésből eredő reaktiválás megakadályozása.

Szükségesség: e cél stabil identity nélkül nem biztosítható ugyanolyan hatékonyan.

Garancia: az identity nem használható személyértékelésre; bizonytalan személy-fiók kapcsolat automatikusan nem köthető össze.

Eredmény: MEGFELELŐ.

6.7. Objektív matching / relevanciaszűrés

A célállapotban nincs score, rank, „top/best” minősítés és nincs természetes személyek egymáshoz viszonyított pontozása.

A szűrés kizárólag az ajánlatkérő által meghatározott, objektív szakmai feltételeken alapulhat, például:

• jogosultsági kód;
• szakmai tevékenység/kulcsszó;
• területi feltétel;
• érvényesség;
• suppression és más kizáró státusz.

Az eredmény sorrendje semleges, determinisztikus (például alfabetikus), és nem személyértékelési rangsor.

Szükségesség: a célzott tender-meghívás relevanciaszűrés nélkül több irreleváns személyt érintene, ezért a szűrés az érintetti beavatkozást is csökkenti.

Eredmény: MEGFELELŐ.

6.8. Pontozás és rangsorolás

A v2 hatálya alatti rendszerben ilyen művelet nincs. A korábbi score/rank megoldás nem része a jelen LIA által igazolt adatkezelésnek.

Eredmény: NEM ALKALMAZANDÓ.

6.9. Matching audit

Cél: utólag vissza lehessen mutatni, hogy milyen objektív feltétel alapján került valaki a potenciálisan releváns körbe.

A célállapotban az audit nem tárol pontszámot vagy rangot. Csak az alkalmazott hard filtereket, az egyezés objektív okát, kizárási okot és az emberi kiválasztás eseményét dokumentálja.

Eredmény: FELTÉTELESEN MEGFELELŐ, rövid és arányos megőrzési idővel.

6.10. Emberi kiválasztás és bulk confirmation

A címzettet az ajánlatkérő választja ki. A rendszer az objektív releváns kört képezi, de nem választ automatikusan címzettet. Nagy címzetti köteg esetén kifejezett emberi megerősítés szükséges és auditált.

A „mind kijelölése” funkció önmagában nem szünteti meg az emberi döntést, de az emberi kontrollnak ténylegesnek kell maradnia: az ajánlatkérő látja a címzetti kört, az alkalmazott szűrőket és a címzettszámot, és külön megerősítést ad.

Eredmény: MEGFELELŐ a fenti guardraillel.

6.11. Meghívó-piszkozat

A piszkozat nyers e-mailt nem tartalmaz; subject identityt, contact referenciát és a tenderhez szükséges szakmai snapshotot kezel.

Eredmény: MEGFELELŐ, feltéve, hogy inaktív piszkozatokra retention szabály működik.

6.12. Tenderenkénti aggregálás és duplicate-send protection

Cél: ugyanazon személy ugyanazon tenderhez ne kapjon munkarészenként külön, feleslegesen ismétlődő cold e-maileket, és változatlan tendert ne lehessen véletlenül újraküldeni.

Az aggregálás az érintetti terhelést csökkentő, a jogos érdek mérlegelését erősítő többletgarancia. Numerikus, minden tenderen átívelő hard frekvenciacap nincs; a rendszer warning-only outreach telemetryt alkalmazhat, amely nem blokkolja a különálló, releváns tenderek kiküldését.

Eredmény: MEGFELELŐ / TÖBBLETGARANCIA.

6.13. Send-time revalidation

Közvetlenül küldés előtt a rendszer fail-closed módon ellenőrzi legalább:

• contact létezését és érvényességét;
• subject identityt és aktív státuszt;
• globális suppressiont;
• a tender és munkarész aktuális relevanciáját;
• a legutolsó rendelkezésre álló snapshot szerinti szakmai jogosultságot;
• provenance meglétét;
• contact freshness státuszt.

Élő MMK/MÉK lekérdezés nincs; a rendszer ezt nem állíthatja. A jogosultsági ellenőrzés a rendelkezésre álló snapshoton alapul.

Eredmény: MEGFELELŐ, és kifejezetten csökkenti az irreleváns vagy tiltakozott címzettnek küldött megkeresés kockázatát.

6.14. JIT contact resolution

A nyers e-mail-cím csak a tényleges küldéshez, közvetlenül a mailer hívása előtt oldható fel, célhoz kötött és naplózott resolveren keresztül.

Eredmény: MEGFELELŐ / TÖBBLETGARANCIA.

6.15. Konkrét tender-meghívás kiküldése

6.15.1. Cél és tartalmi korlát

A v2 alatt jogos érdekre alapított cold tender-meghívó kizárólag konkrét beszerzési/RFQ célú lehet. A levélben:

• RENEXUS logó és RENEXUS név maradhat;
• az ajánlatkérő neve és konkrét beszerzési igénye az elsődleges tartalom;
• rövid, tényszerű 2–3 mondatos magyarázat maradhat arról, hogy a RENEXUS milyen ajánlatkérési rendszer és miért ezen keresztül érkezik a tender;
• a konkrét tender megtekintéséhez egyetlen operatív CTA maradhat: „Tender megtekintése”;
• a tender alapinformációinak login nélküli megtekintése biztosítandó;
• az ajánlatadáshoz szükséges későbbi regisztráció a részvételi folyamat technikai feltételeként jelezhető.

A levél nem tartalmazhat általános RENEXUS-platformmarketinget, különösen:

• „ingyenes” mint értékesítési érv;
• általános REGISZTRÁCIÓ vagy „csatlakozz” CTA;
• homepage-promóciót;
• szolgáltatás- vagy funkciólistát;
• előfizetés-promóciót;
• upsellt vagy newsletter-promóciót.

6.15.2. Reklámjogi határ

A RENEXUS álláspontja szerint az így korlátozott levél elsődleges és közvetlen célja a címzett saját szakmai szolgáltatására vonatkozó konkrét ajánlatkérés közvetítése, nem pedig a RENEXUS szolgáltatásának értékesítésének vagy igénybevételének előmozdítása. Ezért védhető álláspont, hogy az ilyen tiszta RFQ-megkeresés nem minősül a Grt. szerinti gazdasági reklámnak.

E minősítéshez ugyanakkor nem áll rendelkezésre RENEXUS-tényállásra közvetlenül alkalmazható hatósági vagy bírósági döntés. Ezért a minősítés residual legal risket hordoz. Amennyiben egy konkrét levél tartalma ténylegesen gazdasági reklámnak minősül, természetes személy címzettnél a Grt. 6. § szerinti előzetes hozzájárulási követelményt nem válthatja ki a GDPR 6. cikk (1) f) pont szerinti jogos érdek.

6.15.3. Szükségesség

A konkrét tenderre való cold megkeresés a RENEXUS discovery-funkciójának lényegi eleme. A kizárólag regisztrált felhasználók értesítése nem egyenértékű alternatíva. A levél tartalma azonban csak a konkrét tenderhez és annak operatív megértéséhez szükséges mértékű lehet.

6.15.4. Érdekmérlegelés

Az érintetti beavatkozást csökkenti:

• a konkrét szakmai relevancia;
• a score/rank hiánya;
• az emberi kiválasztás;
• egy tenderhez egy aggregált e-mail;
• változatlan tender duplikációtilalma;
• send-time revalidation;
• JIT contact resolution;
• jól látható és globális tiltakozási lehetőség;
• a teljes Article 14 layered notice;
• a tender login nélküli megtekinthetősége.

Eredmény: FELTÉTELESEN MEGFELELŐ, kizárólag a 6.15.1–6.15.4 pontok és a 9–10. fejezet garanciáinak együttes működése mellett.

6.16. Meghívási esemény és történeti audit

A küldés, blokkolás, újraküldés, módosult tender értesítés és kapcsolódó események auditja az elszámoltathatóság és viták rendezése miatt szükséges lehet. A nyers e-mail-cím cold meghívónál nem kerül az általános email logba; contact referencia és keyed hash használható.

Eredmény: FELTÉTELESEN MEGFELELŐ, arányos retention mellett.

6.17. Globális suppression

6.17.1. Érintetti tiltakozás

Az érintett „ne keressenek többet” nyilatkozata subject-level, forrásfüggetlen suppressiont hoz létre. E státusz fennmarad ahhoz szükséges minimális identity-adattal, hogy egy későbbi új adatforrás vagy új e-mail-cím ne kerülhesse meg a tiltakozást.

Eredmény: MEGFELELŐ / KÖTELEZŐ JOGGYAKORLÁST BIZTOSÍTÓ MŰVELET.

6.17.2. Hard bounce / invalid address

Címszintű technikai blokkolás a felesleges ismételt kézbesítési kísérletek megakadályozására.

Eredmény: MEGFELELŐ.

6.17.3. Marketing-only tiltás

A marketing-only suppression nem keverhető össze automatikusan a tender-RFQ vagy tranzakciós kommunikációval; a scope-nak egyértelműnek kell lennie.

Eredmény: FELTÉTELESEN MEGFELELŐ, pontos scope-kezeléssel.

6.18. Vault access log és security audit

A raw contacthoz való hozzáférések naplózása a biztonság és elszámoltathatóság érdekében szükséges. A log nyers contactot nem tartalmazhat.

Eredmény: MEGFELELŐ, arányos megőrzési idővel.

6.19. Jelölt és regisztrált fiók összekapcsolása

A stabil, bizonyított 1:1 kapcsolat segítheti a cold és registered-user állapotok kezelését. Bizonytalan e-mailes egyezés nem hozhat automatikus linket.

Eredmény: FELTÉTELESEN MEGFELELŐ, átláthatóság és bizonytalanság esetén no-link szabály mellett.

6.20. AK saját beszállítói lista

A kézzel vagy Excelből feltöltött, az AK saját forrásából származó beszállítói adat kezelésének jogalapját az AK határozza meg. A RENEXUS e műveletben adatfeldolgozó lehet, ha az adat nem kerül a saját discovery indexbe.

Eredmény: a RENEXUS saját 6. cikk (1) f) LIA-ja NEM ALKALMAZANDÓ; külön 28. cikk szerinti konstrukció szükséges.

6.21. Historikus legacy PII

A régi meghívó-, queue-, token-, log-, suppression- és archivált rekordok nyers e-mail-adatainak megőrzését nem igazolja automatikusan a jelen LIA. Ezekre tételes historical-retention/remediation döntés szükséges.

Eredmény: A JELEN LIA NEM IGAZOLJA.

6.22. Meghívó megnyitásának és regisztrációjának eseménye

A konkrét tender-meghívó tokennel történő megnyitása és a kapcsolódó regisztrációs esemény a tenderfolyamat működtetéséhez és auditjához korlátozottan kezelhető. Láthatatlan tracking pixel vagy általános viselkedésprofil nem része a célállapotnak.

Eredmény: FELTÉTELESEN MEGFELELŐ, rövid retention és világos tájékoztatás mellett.

6.23. Meghívó-tokenes regisztráció kötött címe

Amennyiben az érintett a konkrét meghívás alapján maga kezdeményezi a regisztrációt és a tenderen való részvételt, a regisztrációs folyamatban kezelt kötött elérhetőség jogalapja a GDPR 6. cikk (1) b) pontja lehet. Nyers e-mail a session cookie-ba nem kerülhet.

Eredmény: MÁS JOGALAP — NEM A JELEN LIA TÁRGYA.

7. Érintetti várakozások és a beavatkozás súlya

7.1. Szakmai kontextus

Az adatkezelés kizárólag az érintettek gazdasági-szakmai szerepéhez kapcsolódik. A RENEXUS nem célzottan magánjellegű elérhetőséget, magánéleti adatot, különleges adatot vagy bűnügyi adatot kezel a discovery és tender-meghívási célból.

A szakmai szerep azonban nem jelenti azt, hogy az érintett korlátlan indexelésre vagy üzleti újrafelhasználásra számít. A strukturált, tartós discovery index az egyszeri forrásmegismeréshez képest többletbeavatkozás. Ennek ellensúlyozása csak tényleges garanciákkal lehetséges.

7.2. Várakozás forrásonként

• Kamarai szakmai jogosultsági adatok: az érintett számíthat arra, hogy jogosultságát és szakmai státuszát harmadik felek ellenőrzik; kevésbé egyértelmű, hogy adatait tartósan külön üzleti indexben kezelik.
• Kamarai e-mail: a nyilvánosság és a harmadik fél tender-meghívási újrafelhasználás közötti kapcsolat nem automatikus; ezért erős transparency, vault-minimalizálás és opt-out szükséges.
• Vállalkozási weboldalon kapcsolatfelvételre közzétett üzleti e-mail: egy szakmailag releváns RFQ-megkeresés közelebb áll a kapcsolatfelvétel észszerű céljához, de az automatizált adatbázis-építés ettől még külön beavatkozás.
• REKORE: a source-status partial, ezért a várakozási érv gyengébb és a felülvizsgálat szigorúbb.

8. Garanciák

A jelen LIA pozitív eredménye a következő garanciák együttes és tényleges működéséhez kötött:

1. 1. Discovery-vault szétválasztás: raw e-mail nincs a discovery master-recordban.
2. 2. Telefon teljes kizárása: a tender-discovery célból telefon nem gyűjthető és nem tárolható.
3. 3. JIT contact resolution: nyers e-mail csak konkrét, engedélyezett purpose esetén oldható fel.
4. 4. RBAC és access log: raw contact-hozzáférés kontrollált és naplózott.
5. 5. Nincs score/rank: a rendszer nem pontoz és nem rangsorol természetes személyeket.
6. 6. Objektív relevanciaszűrés: jogosultság, szakmai kulcsszó, földrajzi feltétel és egyéb tényszerű hard filter.
7. 7. Emberi címzett-kiválasztás: a rendszer nem választ autonóm módon címzettet.
8. 8. Bulk confirmation: nagy címzetti kör külön emberi megerősítést igényel.
9. 9. Tenderenkénti aggregálás: ugyanazon alany azonos tenderhez egy cold levelet kap az összes releváns munkarésszel.
10. 10. Duplikációtilalom: változatlan tender ugyanannak az alanynak nem küldhető ki új outreachként ismételten.
11. 11. Warning-only outreach telemetry: frekvencia megfigyelhető, de nincs általános numerikus hard cap; a relevancia és duplikációkontroll kötelező.
12. 12. Send-time fail-closed revalidation: suppression, identity, relevancia, snapshot-eligibility, provenance és freshness ellenőrzés.
13. 13. Globális, source-independent suppression: az érintett tiltakozását új forrás vagy új e-mail nem kerülheti meg.
14. 14. Rétegzett Art. 14 tájékoztatás minden cold levélben.
15. 15. Jól látható tiltakozási blokk minden cold levélben.
16. 16. RFQ-only kommunikáció: a RENEXUS-brand és működési magyarázat maradhat, általános marketing-CTA és platform-promóció nem.
17. 17. Login nélküli tender-alapnézet.
18. 18. Source-date freshness: a migráció időpontja nem minősül az adat frissességi dátumának.
19. 19. Nincs új periodikus full kamarai scraping.
20. 20. Retention-infrastruktúra: megőrzési szabályok reportolhatók, később dokumentált döntéssel enforce-olhatók.
21. 21. Filesystem PII-hardening: world-readable/world-writable PII és backup nem megengedett.
22. 22. Security boundary: production secrets és backupok korlátozott hozzáférésűek.

9. GDPR 14. cikk — tájékoztatási modell

9.1. Általános szabály

Mivel a discovery/vault adatok jellemzően nem közvetlenül az érintettől származnak, a GDPR 14. cikke alkalmazandó. A RENEXUS nem alkalmazhat olyan általános fikciót, amely szerint minden még meg nem keresett személy automatikusan a 14. cikk (5) b) szerinti „aránytalan erőfeszítés” kivétel alá esik.

9.2. Első cold kapcsolatfelvétel

Minden cold tender-meghívóban már láthatóan szerepelnie kell legalább:

• az adatkezelő(k) azonosításának;
• annak, hogy a címzett miért kapta a levelet;
• az adatforrás vagy forráscsalád megjelölésének;
• a kezelt adatkategóriák rövid megjelölésének;
• a jogalapnak és a jogos érdek rövid megjelölésének;
• a tiltakozási jogra történő egyértelmű felhívásnak;
• a teljes adatkezelési tájékoztatóra mutató linknek.

A teljes tájékoztató tartalmazza a 14. cikk valamennyi alkalmazandó elemét.

9.3. Még meg nem keresett discovery-rekordok

A még meg nem keresett személyek tekintetében a RENEXUS külön, dokumentált proportionality assessment alapján értékelheti a 14. cikk (5) b) esetleges alkalmazhatóságát. A kivétel nem lehet automatikus, és a RENEXUS-nak megfelelő intézkedéseket kell fenntartania, ideértve a nyilvános adatgyűjtési/privacy oldalt és az előzetes tiltakozás jövőbeli lehetőségét.

9.4. Történeti hiány

A már korábban betöltött és a target-state production rollout előtt megfelelő 14. cikk szerinti egyedi tájékoztatásban nem részesült érintetteknél a korábbi határidő elmulasztása nem orvosolható visszamenőleg azzal, hogy a jövőbeni levél már megfelelő. A kérdést a DPIA és a historical-remediation terv külön residual riskként kezeli.

10. GDPR 21. cikk — tiltakozás

A cold tender-meghívásban a tiltakozás lehetőségét a többi információtól egyértelműen elkülönítve és jól láthatóan kell bemutatni.

Az érintett tiltakozását a RENEXUS a cold tender-outreach tekintetében önkéntesen feltétel nélküli globális suppressionként teljesíti: tiltakozás esetén új cold tender-meghívás nem küldhető, függetlenül attól, hogy ugyanaz az érintett később új forrásból vagy új e-mail-címmel kerülne elő.

A suppressionben csak a tiltás érvényesítéséhez szükséges minimális identity/contact-hash és scope tartható meg.

11. Megőrzés és felülvizsgálat

11.1. Elv

A RENEXUS nem alkalmazza a „cél fennállásáig” általános, korlátlan formulát. Minden adatcsoporthoz külön retention vagy review szabály szükséges. A konkrét policy-idők — ha nem jogszabályi határidők — üzemeltetési/érdekmérlegelési döntések, nem safe harbour értékek.

11.2. v2.0 minimum retention-mátrix

A production rolloutban a 0093-mal bevezetett retention-infrastruktúra enforcementje első körben report/dry-run marad; ez nem érinti a levéltörzs már működő, 90 napos törlését. Destruktív enforcement csak a DPIA és a végleges retention matrix jóváhagyása után aktiválható.

12. Adatbiztonsági és szervezési intézkedések

A releváns intézkedések különösen:

• discovery-vault rétegszétválasztás;
• adatbázis-szerepkörök és SECURITY DEFINER resolver;
• cél-enum szerinti contact-feloldás;
• access logging;
• exportkorlátozás;
• nyers cold-contact hiánya a normál frontendben, matching auditban, sessionben és cold email logban;
• production secret- és backup-jogosultságok szűkítése;
• world-readable/world-writable PII-fájlok megszüntetése;
• globális suppression;
• send-time fail-closed revalidation;
• source-date freshness.

Ismert maradványkockázatok:

• a vault raw értéke alkalmazásszinten nincs at-rest titkosítva;
• a kulcsolt hash (HMAC) a vaultban és a suppressionben implementált, de kulcsrotáció nincs, és a mezőszintű provenance e-mail-értékhash-e még kulcs nélküli;
• access log nem WORM;
• superuser/backup szinten raw contact hozzáférés technikailag lehetséges;
• live kamarai revalidation nincs.

E kockázatokat a DPIA részletesen értékeli.

13. Profilalkotás és automatizált döntéshozatal

A v2 célállapotban a RENEXUS személyekre vonatkozó pontszámot vagy rangot nem állít elő. Az objektív jogosultsági, szakmai és földrajzi filterek célja nem személyes teljesítmény, megbízhatóság, preferencia vagy viselkedés értékelése, hanem annak tényszerű vizsgálata, hogy a nyilvános szakmai attribútum megfelel-e az ajánlatkérő által megadott tenderfeltételnek.

A rendszer a címzettet nem választja ki automatikusan; a címzettet az ajánlatkérő választja. Nagy köteg esetén kifejezett megerősítés szükséges.

AI kizárólag a tender/munkarész szakmai követelményének javaslatához használható; az AI-javaslat emberi jóváhagyás nélkül nem válhat aktív matching feltétellé. A személyek matching- és küldési döntésében, valamint a címzettek kiválasztásában AI, LLM vagy embedding nincs. A vállalkozási weboldal-forrás 2026. júniusi, egyszeri előállításakor a vállalkozások tevékenységi besorolását LLM-alapú osztályozás segítette; e forrás 2026. szeptember 23. óta a keresésből és a meghívási folyamatból ki van zárva.

A send-time revalidation egyes esetekben automatikusan blokkolhatja a küldést, de nem választ helyette más címzettet és nem hoz az érintettre nézve joghatással vagy ahhoz hasonlóan jelentős hatással járó döntést. E minősítést a DPIA is felülvizsgálja.

14. RFQ és marketing elkülönítése

A 6. cikk (1) f) szerinti jelen LIA nem terjed ki RENEXUS-marketing, newsletter, szolgáltatás-promóció, upsell vagy általános tagszerzési kommunikáció küldésére.

A cold tender-meghívás csak akkor tartozhat a jelen LIA alá, ha tartalmilag konkrét RFQ marad. A RENEXUS-brand és a rendszer rövid működési magyarázata önmagában nem tiltott, ha kizárólag a konkrét tenderfolyamat megértését szolgálja, és nem alakítja át a levelet a RENEXUS szolgáltatásának értékesítését előmozdító közléssé.

Ha egy üzenet tényleges tartalma gazdasági reklám, arra a jelen LIA nem használható a Grt./Ektv. szerinti hozzájárulási követelmény megkerülésére.

15. DPIA

A RENEXUS a v1 korábbi „DPIA nem szükséges” következtetését nem tartja fenn. A processing skálája, a több nyilvános forrás kombinálása, a discovery index, a matching, a cold contactkezelés és a történeti gyakorlat alapján teljes DPIA készítendő.

A DPIA legalább a következőket vizsgálja:

• nagy lépték;
• több forrás kombinálása;
• nyilvános adat újrafelhasználása;
• forrás- és adatbázisjogi kockázatok;
• contact-vault;
• Article 14;
• suppression;
• send-time revalidation;
• historical legacy PII;
• korábbi score/rank történeti használata;
• biztonsági kontrollok és residual riskek;
• állami/önkormányzati pilot esetleges eltérő jogalapjai és szerepei.

16. Történeti eltérések és maradványkockázatok

A jelen LIA kifejezetten rögzíti, hogy a target-state production rollout előtti rendszerben (amely 2026. szeptember 24-én productionben még aktív) több olyan elem működött, amely a v2 célállapotban már nem marad fenn vagy külön remediation tárgya:

1. 1. a cold e-mailben RENEXUS-promóciós/regisztrációs elemek szerepeltek;
2. 2. az első levél nem tartalmazta a teljes layered Art. 14 tájékoztatást;
3. 3. telefonszámok kerültek tárolásra tényleges runtime cél nélkül;
4. 4. score és rank készült;
5. 5. ugyanazon tender több munkarésze külön e-maileket generálhatott;
6. 6. nem működött konkrét retention matrix;
7. 7. historical legacy táblák nyers e-mail-adatot őriznek;
8. 8. a forrásjogi/adatbázisjogi due diligence egyes kamarai kérdései nem zártak;
9. 9. a korábbi GDPR 14 határidő mulasztása nem orvosolható visszamenőleg;
10. 10. a joint-controller és processor szerződéses keret még véglegesítendő.

E pontok nem „megszűntként” dokumentálandók mindaddig, amíg az adott remediation ténylegesen le nem zárult.

17. Eredménymátrix

18. Konklúzió

A RENEXUS discovery- és konkrét tender-RFQ rendszerének műveletei jelentős részben alapíthatók a GDPR 6. cikk (1) f) pontjára, de kizárólag a jelen dokumentumban leírt, szűk célállapot és garanciák mellett.

A pozitív mérleg különösen azon alapul, hogy a v2 célállapot:

• nem használ telefonszámot;
• nem pontoz és nem rangsorol személyeket;
• nem használ AI-t személyek kiválasztására;
• a contactadatot elkülönített vaultban tartja és JIT módon oldja fel;
• a címzettet ember választja;
• ugyanazon tenderhez aggregálja a munkarészeket;
• blokkolja a változatlan tender ismételt cold kiküldését;
• minden küldés előtt újraellenőriz;
• forrásfüggetlen globális suppressiont tart fenn;
• az első cold levélben Article 14 short layert és jól látható tiltakozást ad;
• a cold levelet konkrét tender-RFQ-ra korlátozza, miközben a RENEXUS-brand és a működés megértéséhez szükséges rövid rendszerismertető megmarad;
• a forrásfrissességet nem a migráció, hanem a tényleges source-date alapján kezeli;
• új periodikus full kamarai scrapinget nem végez.

A LIA pozitív eredménye nem általános felhatalmazás a források korlátlan újrafelhasználására és nem oldja fel a külön adatbázisjogi, szerződéses vagy reklámjogi korlátokat. A forráshasználati és adatbázisjogi kérdések külön jogterületként fennmaradnak.

A jelen LIA nem alkalmazható olyan cold e-mailre, amely tényleges tartalma szerint RENEXUS-marketing vagy gazdasági reklám; nem alkalmazható telefonszám-kezelésre; nem igazolja a legacy PII határozatlan megőrzését; és nem helyettesíti a kötelező DPIA-t, a GDPR 26. cikk szerinti közös adatkezelési megállapodást vagy a GDPR 28. cikk szerinti DPA-t.

19. Felülvizsgálat

A LIA-t soron kívül felül kell vizsgálni különösen, ha:

• új adatforrás kerül be;
• MMK/MÉK/REKORE felhasználási feltétele vagy jogi helyzete érdemben változik;
• ismét bevezetésre kerülne pontozás, rangsorolás vagy személyprofil;
• AI/LLM kerülne be a személyek kiválasztásába;
• új kommunikációs csatorna kerül be;
• a cold e-mail általános RENEXUS-marketinget kapna;
• megváltozik az adatkezelői/joint-controller/processor modell;
• állami vagy önkormányzati pilot indul;
• a retention enforcement aktiválódik vagy lényegesen változik;
• adatvédelmi incidens vagy jelentős érintetti panasz következik be;
• hatósági vagy bírósági döntés érinti a RENEXUS által használt jogértelmezést.

Rendes felülvizsgálat: legalább évente, továbbá a DPIA minden érdemi frissítésekor.

20. Jogforrási és módszertani jegyzék

A dokumentum különösen az alábbi jogforrásokra és értelmezési anyagokra épül:

• Az Európai Parlament és a Tanács (EU) 2016/679 rendelete (GDPR), különösen 5., 6., 12–14., 21., 22., 24–26., 28., 32. és 35. cikk;
• GDPR (47), (61), (69), (70), (71) preambulumbekezdés;
• EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR;
• EDPB/WP29 transparency guidance (WP260 rev.01);
• EDPB/WP29 DPIA guidance (WP248 rev.01);
• EDPB/WP29 automated decision-making and profiling guidance (WP251 rev.01);
• EDPB Guidelines 4/2019 on Article 25 Data Protection by Design and by Default;
• EDPB Guidelines 1/2024 on Article 6(1)(f), a dokumentum 2026-09-24-i státuszának megfelelően, nem végleges iránymutatásként kezelve;
• EUB C-621/22, C-252/21, C-708/18, C-13/16, C-394/23, C-40/17, C-210/16, C-25/17, C-683/21 és a dokumentumban relevánsan hivatkozott további ítéletek;
• 2008. évi XLVIII. törvény (Grt.), különösen 3. § d) és 6. §;
• 2001. évi CVIII. törvény (Ektv.), különösen 14. §;
• 2003. évi C. törvény, különösen a közvetlen üzletszerzési opt-out szabályok;
• 2011. évi CXII. törvény (Infotv.);
• 2023. évi C. törvény (Méptv.), különösen 207. §;
• 266/2013. (VII. 11.) Korm. rendelet, különösen 30. §;
• releváns NAIH-, NMHH- és kúriai gyakorlat.

21. Implementációs elfogadási kapu

A dokumentum csak akkor jelölhető HATÁLYOS státuszúnak, ha a CC production rollout-jelentése igazolja legalább az alábbiakat:

• 0093 és 0094 sikeresen productionben aktív;
• aktív telefon-contact = 0;
• telefon ETL = 0;
• score = nincs;
• rank = nincs;
• objektív matching audit működik;
• emberi kiválasztás és bulk confirmation működik;
• ugyanazon subject + tender munkarészei egy cold e-mailbe aggregálódnak;
• változatlan tender duplicate-send védelme működik;
• új cold e-mail sablon a végleges GPT-szöveget használja;
• Art. 14 short layer ténylegesen megjelenik;
• jól látható tiltakozási blokk és globális suppression működik;
• login nélküli tendernézet működik;
• nyers cold email nincs sessionben és új cold email logban;
• source-date freshness működik;
• full periodic chamber refresh tiltott;
• retention első körben report-only;
• filesystem PII-hardening zöld;
• regression, PII-scan és mock/controlled send QA zöld.

E kapu teljesülése után a hatálybalépés dátuma és a végleges verzióazonosító tölthető ki.