GDPR adatmentés: mit követel meg a rendelet a SaaS-adatoktól

A GDPR adatmentés témája azért marad sokszor észrevétlen, mert a rendelet szövege ki sem mondja a „mentés” szót. A 32. cikk (1) bekezdés c) pontja viszont kifejezetten előírja azt a képességet, hogy „fizikai vagy műszaki incidens esetén a személyes adatokhoz való hozzáférést és az adatok rendelkezésre állását kellő időben vissza lehessen állítani” — a d) pont pedig azt, hogy ezt rendszeresen tesztelni is kell. Ha az Ön Microsoft 365-, Google Workspace-, Slack- vagy Atlassian Cloud-adatainak nincs más helyreállítási útja, mint a néhány hetes kuka, az nem csupán üzemeltetési kockázat, hanem megfelelési hiányosság.

Az alábbiakban végigvesszük, mit vár el ténylegesen a rendelet, hol marad el ettől a natív megőrzés, és hogyan viszonyul a törléshez való jog a mentésekhez.

Az adatvesztés akkor is incidens, ha senki nem vitt el semmit

A 4. cikk 12. pontja szerint adatvédelmi incidens „a biztonság olyan sérülése, amely a továbbított, tárolt vagy más módon kezelt személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy az azokhoz való jogosulatlan hozzáférést eredményezi”. A felsorolás első három eleme a megsemmisítés, az elvesztés és a megváltoztatás — adatkiszivárgás nélkül is.

Ennek közvetlen következménye van a zsarolóvírusokra nézve. Ha egy támadás titkosítja a SharePoint-tárat vagy a megosztott Drive-ot, de egyetlen bájtot sem visz ki a bérlőből, az akkor is a rendelkezésre állás sérülése, tehát a 33. cikk szerint bejelentésköteles incidens lehet — a 72 órás határidő pedig attól kezdve ketyeg, hogy Önök tudomást szereztek róla. Magyarországon a bejelentés címzettje a Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH).

A lényeg: a mentés nem pusztán üzemeltetési eszköz, hanem tényező a saját incidens-kockázatértékelésükben is. Ha van megbízható, tesztelt visszaállítás, az érintettekre gyakorolt kockázat érdemben más megítélés alá esik, mint ha nincs.

Mit ír elő a 32. cikk a gyakorlatban

A 32. cikk a kockázattal arányos intézkedéseket követel meg, a tudomány és technológia állására, a megvalósítás költségeire, valamint az adatkezelés jellegére és céljaira tekintettel. Négy elem érinti közvetlenül a mentést:

• A rendelkezésre állás és az ellenálló képesség biztosítása (32. cikk (1) b) pont) — nem csak a bizalmasságé.
• A kellő időben történő helyreállítás képessége incidens után (c) pont).
• Rendszeres tesztelés, felmérés és értékelés (d) pont).
• Mindezek fölött az 5. cikk (2) bekezdése: az elszámoltathatóság elve alapján a megfelelést igazolni is kell tudni, nem elég állítani.

A „kellő idő” szándékosan nincs számszerűsítve: a kockázattal együtt mozog. Egy soha le nem tesztelt visszaállítás viszont a d) pont szó szerinti olvasata szerint még nem olyan intézkedés, amelynek a hatékonyságát értékelték volna.

Hol marad el ettől a natív megőrzés

A nagy SaaS-platformok beépített megőrzése a véletlen törlés esetére készült, és három ponton marad el a 32. cikk elvárásaitól:

• Gördülő ablak, nem időpontra visszaállítás. A nemrég törölt elem többnyire visszahozható. Az viszont általában nem, hogy „a bérlő állapota 14-én reggel” — pedig tömeges titkosításnál vagy sérülésnél pontosan erre van szükség.
• Közös kockázati kör. A bérlőn belül tárolt adat osztozik a bérlő sorsán: rendszergazdai jogosultsággal a támadó az éles adat mellett a kukát is ürítheti. Ez a megosztott felelősségi modell lényege — a szolgáltató a platformért felel, az adatkezelő továbbra is Önök.
• Nincs bizonyíték. Nincs visszaállítási jegyzőkönyv, mért helyreállítási idő, megőrzési igazolás, amit a hatóság elé lehetne tenni — az elszámoltathatóság viszont bizonyítási kötelezettség.

A részletek platformonként eltérnek — a Slack megőrzési logikája ritkán az, amire az adminok számítanak —, de a hiányosság alakja mindenhol ugyanaz.

A törléshez való jog és a mentések

Itt akad el a legtöbb belső egyeztetés: ha egy érintett a 17. cikk szerinti törlést kéri, ki kell-e sebészi pontossággal vágni őt minden mentési példányból?

A felügyeleti gyakorlatban kialakult, pragmatikus álláspont szerint a törlésnek ki kell terjednie a mentésekre is, de az követheti a mentés saját életciklusát. Ha az adat a mentésből nem törölhető azonnal, akkor használaton kívülre kell helyezni: rendes adatkezelésre nem elérhető, védett, és a mentési példány felülírásakor vagy lejáratakor megszűnik. Ezt a megközelítést a brit ICO iránymutatása fogalmazza meg a legexplicitebben, és hasznos viszonyítási pont az EU-ban is — a konkrét elvárást azonban érdemes a NAIH álláspontjához igazítani, nem feltételezni.

Működési szempontból az számít, hogy ez dokumentált, tudatos folyamat legyen, ne rögtönzés:

• Írásos megőrzési és lejárati rend a mentési példányokra, hogy a „majd egyszer” konkrét dátum legyen.
• Kontroll arra, hogy egy későbbi visszaállítás ne hozza vissza észrevétlenül a törölt adatot.
• Az érintettnek adott válasz, amely őszintén megnevezi a határidőt.

Egy rövidebb megőrzési idő, amelyet pontosan le tudnak írni, védhetőbb, mint egy hosszabb, amelyről senki nem tud számot adni.

A korlátozott tárolhatóság mindkét irányba vág

Az 5. cikk (1) bekezdés e) pontja szerint a személyes adat nem tárolható tovább, mint amennyi a célhoz szükséges. A határozatlan idejű mentésmegőrzés tehát nem az az automatikusan biztonságos választás, aminek elsőre tűnik. A védhető válasz egy tudatosan meghatározott, célhoz kötött, dokumentált megőrzési idő, amelyet a rendszer ténylegesen ki is kényszerít.

A SaaS-szolgáltató adatfeldolgozó — és ez szerződéses kérdés

A 28. cikk alapján az adatfeldolgozónak meg kell valósítania a 32. cikk szerinti intézkedéseket, és segítenie kell Önöket a saját kötelezettségeik teljesítésében; mindezt írásos adatfeldolgozói szerződés rendezi. A Microsoft, a Google, a Slack és az Atlassian is kínál ilyet. Amit viszont egyikük sem vállal át, az az adatkezelő kötelezettsége a saját adatai visszaállítására a saját incidense után — hogy ez a határ hol húzódik, azt a Microsoft 365 és a Google Workspace platformoldalunk munkakörönként bontja ki. Ha Önök már dolgoznak a NIS2 mentési követelményein, az ott felépített bizonyítékrendszer a GDPR elszámoltathatóságának nagy részét is lefedi.

GDPR adatmentés: gyakorlati ellenőrzőlista

• Térképezze fel a személyes adatokat minden SaaS-bérlőben — postafiókok, Drive-fájlok, Teams- és Slack-üzenetek, Jira-jegyek és Confluence-oldalak rendszeresen tartalmaznak ilyet, és a 30. cikk szerinti nyilvántartásban is szerepelniük kell.
• Határozzon meg helyreállítási pontot és időt munkakörönként, majd tesztelje is, ne becsülje.
• Tartson független másolatot a bérlőn kívül, hogy egy bérlőszintű kompromittálódás ne érje el.
• Őrizze meg a visszaállítás bizonyítékát — dátumozott jegyzőkönyvet arról, mit állítottak vissza és mennyi idő alatt.
• Írja le a törlés és a mentés viszonyát még azelőtt, hogy valaki a 17. cikkre hivatkozna.
• Tesztelje újra ütemezetten. A d) pont szerint a nem tesztelt kontroll nem értékelt kontroll.

A 30 másodperces önteszt

Tegye fel a kérdést: „Ha ma éjjel egy zsarolóvírus titkosítaná a bérlőnket, vissza tudnánk állítani a benne lévő személyes adatokat — és tudnánk igazolni, mennyi idő alatt?” Ha a válasz nem, a rendelkezésre állási hiányosság már most fennáll; a 33. cikk csak az a pillanat, amikor láthatóvá válik.

Ennek a képességnek a kiépítésében segítünk Microsoft 365, Google Workspace, Slack és Atlassian Cloud környezetben: segítünk kiválasztani a rendszerükhöz illő megoldást, és végigkísérjük a bevezetést, hogy legyen független, időpontra visszaállítható másolat, tesztelt helyreállítás és auditálható bizonyíték. A megoldást ezután Önök birtokolják és üzemeltetik.

---

Szeretné tudni, hol tartanak? Kérjen ingyenes kockázatfelmérést — átnézzük a SaaS-bérlőiket a GDPR helyreállítási és bizonyítási elvárásai mentén, és őszinte listát adunk a hiányosságokról.