Adatkezelés a pályázatfigyelésben: cégadat, jogalap, megőrzés

A megtekintési és riportolási adatok is új célnak számítanak. Az, hogy a felhasználó megnyitott egy pályázatot, segíthet a szolgáltatás minőségének értékelésében, de a riport saját logóval, színnel, lábléccel és cégnévvel készül, ezért már a felhasználó üzleti környezetéhez kapcsolódik. A saját-branding funkció előnyös, viszont az ügyfélnek ellenőriznie kell, hogy a logó, a cégnév és a kimeneti dokumentum nem tartalmaz-e olyan belső adatot, amelyet a felhasználó nem kíván a riportban továbbítani. A cél meghatározása itt nem pusztán jogi mondat: megmondja, milyen mezőket kell gyűjteni és mit nem.

A döntéshozó ezért a rendszeradatokat három rétegben érdemes vizsgálni. Az első réteg a nyilvánosan elérhető forrásból származó cég- és pályázatadat; a második a felhasználó által megadott keresési és fiókadat; a harmadik a technikai működést biztosító biztonsági és naplóadat. Mindhárom réteg eltérő kezelési célhoz és megőrzési határidőhöz tartozhat. A vizsgálatban azt kell dokumentálni, melyik rétegbe kerül az adat, milyen jogalapot alkalmaznak, ki férhet hozzá, és hogyan akadályozzák meg a szükségtelen másolást. Enélkül a „nyilvános” előtag könnyen elfedi a tényleges adatkezelési környezetet.

A gyakorlatban a jogalap és a megőrzés akkor kezelhető tisztán, ha a rendszer nem egyetlen „felhasználói adat” kategóriát ismer. A keresési kifejezés, a megtekintési előzmény, a riport tartalma és a biztonsági napló külön célhoz és külön megőrzési szabályhoz kapcsolódhat. Például az adószám szerinti keresés műveleti naplója rögzítheti, hogy a felhasználó milyen azonosítóval és mikor keresett; a keresési kifejezés tartalma ettől még nem kerül automatikusan ugyanabba a naplóba. A riport előállításakor keletkező vállalati és technológiai jellemzők pedig már a szolgáltatás eredményének részei, ezért azok kezelését a riportkészítés céljával kell összevetni.

A jogalap értékelését a NIS2 és a 2024. évi kiberbiztonsági törvény környezetében nem szabad elválasztani a technikai kontrolloktól. A NIS2 célja az egységes belső piaci feltételek megteremtése; a 2024. évi kiberbiztonsági törvény pedig a hazai kiberbiztonsági követelményeket állapítja meg. Ezek az eszközök elsődlegesen a biztonsági szolgáltatásokra, illetve a kiberbiztonsági szabályozás hatályára vonatkoznak, ezért nem helyettesítik a GDPR értékelését. A kockázatkezelés annál inkább releváns, mert egy pályázatfigyelő szolgáltatás üzleti és technikai információkat kezel, és incidens esetén a hatósági bejelentési és ügyfél tájékoztatási folyamatot is be kell indítani.

A jogalap dokumentációjának minimális tartalma a cél, a kezelt adatok, az érintettek köre, a szükségesség, a lehetséges jogszerű alternatívák, a megőrzés, a hozzáférés és a visszavonás vagy korlátozás kezelése. A nyilvános adatforrás nem változtatja meg azt a követelményt, hogy a szolgáltató pontosan megmondja, mit gyűjt. Ha a rendszer külső forrást is feldolgoz, az adatforrás-hitelesítés és a változások figyelése csökkenti a hibás vagy félrevezető vállalati adatok kockázatát. A döntéshozó ezért ne a jogalap címkéjét, hanem a hozzá tartozó döntési jegyzőkönyvet kérje.

A jogalapvizsgálatot cél szerint kell dokumentálni: a szolgáltató rögzítse, hogy a pályázatfigyelés mely adatokat gyűjti, milyen szerepben kezeli őket, meddig tartja meg őket, és kiknek adja tovább. A nyilvános cégadatok kiindulási pontot jelentenek, nem automatikus felhatalmazást minden célra. A pályázati hirdetményekben szereplő kapcsolattartási adatok kezelését ezért külön kell indokolni, különösen akkor, ha a szolgáltató a hirdetés tartalmát a felhasználó riportjaiban ismételteti. A reklamációs célnál nem elég visszautalni az eredeti gyűjtési célra: meg kell mutatni, hogy az érintett észrevétele kezeléséhez az adat további felhasználása valóban szükséges.

A nyilvános cégadat frissítése és a történeti állapot megőrzése más kérdés. Ha a forrás naponta frissül, a rendszer tárolhatja a legfrissebb állapotot az érdeklődő vállalkozásról, de nem szükségszerűen az összes korábbi verziót. A változáskövetés hasznos lehet a kockázati profilokhoz és riportokhoz, ám annak ideje, tartalma és hozzáférési köre külön dokumentációt igényel. A döntéshozónak azt kell kérdeznie, hogy egy régi cégadatváltozásnak van-e még üzleti vagy bizonyítéki értéke; ha nincs, az automatikus megtartás indokolatlan lehet.

A törlés technikai megvalósítása nem pusztán adatbázis-parancs. A mentett riportok, exportok, gyorsítótárazott keresési eredmények és külső integrációs célpontok is befolyásolhatják a határidő betartását. A szolgáltató mutassa be a törlési munkafolyamatot, a sikeres és sikertelen törlések naplóját, valamint az archivált vagy biztonsági mentésekre vonatkozó kivételeket. Az ISO/IEC 27001 kontrolljai ilyenkor a hozzáférési jogosultságok, a biztonsági mentések és a kivételkezelés vizsgálatához adnak keretet. A felhasználó pedig a saját oldalán ne csak a felületi törlésben bízzon meg, hanem a visszaigazolást is kérje.

A megőrzési határidő meghatározásakor a rendszernek először azt kell rögzítenie, hogy egy adott bejegyzés mely kezelési célhoz és mely dokumentumkategóriához tartozik. A vállalkozás aktuális cégprofilja például a szolgáltatás működéséhez, az adószám-lekérdezés a szolgáltatás teljesítéséhez, a biztonsági esemény pedig a rendszer integritásának vizsgálatához kapcsolódhat. Ezek külön kezelési célok, ezért az egyik megszűnése nem törli automatikusan a másikhoz szükséges adatot. A gyakorlati megoldás az, ha a rendszer minden bejegyzéshez kezelési célt, kockázati kategóriát és megőrzési határidőt rendel.

A törlési kérés feldolgozását érdemes eseményenként megvalósítani, nem pusztán a felhasználó fiókja alapján. Az adószám lekérdezés, az AI-illesztés és a pályázatmegtekintés külön esemény, és ezekhez eltérő jogosultság, megőrzési cél és bizonyítéki érték társulhat. A rendszer először azonosítja a kérelemmel érintett eseményeket, majd megkülönbözteti a törlendő üzleti adatot, a megőrzési kötelezettség alá eső adót, a biztonsági eseményt és a jogi igény érvényesítéséhez szükséges bizonyítékot. A törlési eljárás naplózza a kérelem beérkezését, az érintett kategóriákat, a kivételek alapját és a végső intézkedést.

A pályázatfigyelő szolgáltató értékelése akkor vezet használható döntéshez, ha a jogszerűséget, a biztonságot, a kapacitást és az adatminőséget egyetlen ellenőrzőtáblázatba rendezi. Az alábbi táblázat nem minősíti az egyes szolgáltatókat; döntési kérdéseket ad át a beszerzőnek, jogi szakértőnek és információbiztonsági vezetőnek.

A táblázat kitöltésekor minden válaszhoz kérj bizonyítékot: adatkezelési táblázatot, megőrzési szabályzatot, incidenskezelési eljárást, hozzáférési képernyőképet vagy mintariportot. A jogalapnál az érdekbevizsgálatot, a megőrzésnél a cél szerinti határidőt, az adatminőségnél a hibajavítási folyamatot kell látni. Ha a válasz csak „megfelel a GDPR-nak” állítás, a döntés nem kész. A NIS2 és a 2024. évi kiberbiztonsági törvény hatályát a vállalkozás mérete, tevékenysége és kapcsolódó szolgáltatásai alapján külön kell megvizsgálni.

A jogalap ellenőrzését három rétegben érdemes elvégezni: először azonosítani kell a szolgáltató által kezelt adatcsoportokat és azok célját; ezután meg kell kérni az érdekbevizsgálatot, amely dokumentálja az adatkezelés szükségességét, a jogalapot és a szolgáltatásnyújtáshoz fűződő viszonyt; végül ellenőrizni kell, hogy a tájékoztató vagy az szerződés ténylegesen összhangban áll-e ezekkel a dokumentumokkal. A cégadat és a kapcsolattartói adatok kezelését nem szabad automatikusan a többi adatcsoporttal azonos elbírálni, mert más cél és más jogalap kapcsolódhat hozzájuk.

A megőrzési szabály megítéléséhez a határidőt cél szerint kell leképezni az adatokra. A pályázati értesítés önmagában nem igazolja azt, hogy minden beérkezett adatot ugyanolyan ideig kell tárolni; a szolgáltató például külön szabályban kezelheti az aktív pályázatok adatait, a lezárt folyamatok nyilvántartását és a biztonsági naplókat. A döntési mátrixban ezért nem elég egyetlen „megőrzési idő” mezőt kérni: rögzíteni kell a kiindulási eseményt, a határidő számításának módját, az automatikus törlés vagy elzárolás folyamatát és azt, hogy a törlés a mentett példányokra is kiterjed-e.

A megőrzési határidő ellenőrzéséhez nem elég egyetlen számot kérni: a szolgáltatótól kifejezetten azt kell számlálni, hogy az érintett adatcsoport mikor és miért lép ki a rendszerből. A cégadatoknál ez általában a szerződés megszűnéséhez vagy az üzleti nyilvántartásból való törléshez kapcsolódik, míg a kapcsolattartói adatoknál a vizsgálat tovább folytatható, ha a pályázatfigyelés célja indokolja. A határidőt a megőrzési szabályzatban, a felhasználói tájékoztatóban és a tényleges technikai megvalósításban egyaránt ellenőrizni kell; eltérés esetén írásbeli magyarázatot kell kérni.