Az adatközpont nem jogi érv

Az adatközpont nem jogi érv

The address on the brochure

There is a sentence that appears in cloud tenders with the confidence of a completed argument: the data will be stored in a European data centre. The sentence may be true. It may also be doing far more work than it can carry.

A data centre has a location. That location matters for physical security, resilience, energy, connectivity, national rules and the practical reach of a local authority. It tells a buyer something useful about where some equipment stands. It does not, by itself, tell the buyer who owns the service, who operates the equipment, where copies are made, who holds the keys, which people can administer it, which companies are allowed to subcontract parts of the work, or which legal system can compel a party to provide access.

The distinction is easy to state and surprisingly easy to lose. A postcode is visible. Control is distributed. The postcode fits neatly in a procurement spreadsheet; control arrives as a chain of contracts, identities, support accounts, management planes, encryption keys, corporate relationships, operational procedures and legal duties. The first is a fact about place. The second is a question about power.

European data protection law has been making this point in increasingly precise language. In the Schrems II judgment of 16 July 2020, the Court of Justice of the European Union examined how personal data could leave the European Economic Area while retaining a level of protection essentially equivalent to the one guaranteed inside it. The Court upheld standard contractual clauses as a possible transfer tool, but made clear that they do not operate in a vacuum. The exporter has to examine the law and practice of the destination in the circumstances of the transfer, and act when the safeguards cannot work in practice.

The judgment did not say that a border is irrelevant. It said that a border is one part of the question. The European Data Protection Board's subsequent recommendations turn that principle into a method: know the transfers, identify the legal tool, assess the law and practice that can affect it, add measures where they can work, complete the required procedure, and keep the assessment under review. A server address appears in that map. It is not the map.

This matters beyond personal data. The Data Act treats cloud and other data-processing services as infrastructure from which customers should be able to switch. It also addresses conditions under which a third-country public authority seeks access to non-personal data held in the Union. Again, the legal answer is built from actors, purposes, safeguards, evidence and remedies. A building is involved. A building is not enough.

The practical lesson for a European institution is therefore blunt. Ask where the data is. Then keep asking questions until the answer includes who can read it, who can change it, who can stop it, who can export it, who can be forced to disclose it, and what evidence will remain when the parties disagree. If the answer ends at the door of the data centre, the useful part of the investigation has only just begun.

Residency is about place

Data residency is a statement about where data is stored or processed under a defined arrangement. The definition needs a scope. Is it the primary copy, the backup, the index, the cache, the telemetry, the disaster-recovery site, or all of them? Does processing include an administrator viewing a record from another country? Does a support session count? What happens when an incident team needs to copy a diagnostic trace? A residency promise that does not say what it covers is an attractive label attached to an unfinished sentence.

A felhőrendszereket arra tervezték, hogy mozgassák a munkát. A replikáció javíthatja a rendelkezésre állást. Egy második helyszín életben tarthat egy szolgáltatást, ha az első helyszín elérhetetlen. Egy peremhelyszín csökkentheti a késleltetést. Egy biztonsági csapat naplót irányíthat egy központi elemzőrendszerbe. Ezek hétköznapi mérnöki döntések, nem pedig visszaélésre utaló jelek. Ugyanakkor azt jelentik, hogy az „Európában tárolva” kifejezéshez műszaki tárgyat kell kapcsolni. Melyik adat, milyen állapotban, milyen időszakra, milyen művelet keretében?

Az ENISA felhőbiztonsági kockázatértékelése, amelyet először 2009-ben tettek közzé, azért maradt hasznos, mert kifejezetten nem kezelte a földrajzi elhelyezkedést teljes körű kontrollként. Azonosítja a több joghatóságban történő tárolásból, a joghatóságokra vonatkozó elégtelen információkból, az irányítás elvesztéséből, az alvállalkozásba adásból és a szolgáltató feletti ellenőrzés változásaiból eredő kockázatokat. A dokumentum elég régi ahhoz, hogy olyan rövidítéseket kedveljen, amelyeket a modern csapatok már nem feltétlenül osztanak, de a szervezeti probléma nem tűnt el. Ha az ügyfél nem látja, hogy hol dolgozzák fel az adatokat, vagy ki a felelős a következő átadásért, az ügyfél nem hozhat megbízható kockázati döntést.

A rezidencia érvényes követelmény lehet. Egy nyilvános levéltárnak szüksége lehet arra, hogy a nyilvántartások egy meghatározott jogi területen belül maradjanak. Egy egészségügyi szolgáltatónak szüksége lehet olyan feldolgozási megállapodásra, amely korlátozza, hogy az érzékeny adatok hová utazhatnak. Egy kutatási konzorciumnak lehetnek kötelezettségei egy finanszírozóval vagy egy adatmegosztási megállapodással kapcsolatban. Ezeket a követelményeket működési feltételekként kell megfogalmazni, az ellenőrzésük módszerével együtt, nem pedig egyetlen országnévként, amelyet mindenki szabadon értelmezhet nagyvonalúan.

Különbség van továbbá a korlátozás és a garancia között. Ha megköveteljük a szolgáltatótól, hogy az elsődleges tárolót az Európai Unióban tartsa, az a mozgás egy osztályát korlátozza. Nem garantálja, hogy az Unión kívüli személy nem férhet hozzá egy rekordhoz, hogy nem távozik metaadat, vagy hogy külföldi jogi kötelezettség nem érheti el a szolgáltatót. Egy korlátozás hasznos lehet anélkül, hogy garancia lenne. A kettő összekeverése olyan megfelelőségi történetet hoz létre, amely átmegy a szerverterem körüli körúton, de megbukik az irányítási sík alaposabb vizsgálatán.

A hasznos rezidenciakérdés nem egyszerűen az, hogy „hol van?”. Hanem az, hogy „mely helyszínek lehetségesek az adat egyes állapotaihoz, és ki tudja azt az állapotot megváltoztatni?”. A szolgáltatónak képesnek kell lennie olyan választ adni, amelyet egy mérnök meg tud valósítani, és egy vevő ellenőrizni tud. Ha a magyarázat egy dokumentálatlan kivételtől, egy támogatási szokástól vagy attól az ígérettől függ, hogy a szolgáltató saját alvállalkozói valószínűleg megfelelően viselkednek, akkor a rezidenciaigény még nem működőképes.

Öt kérdés, amely a „hol” szó mögött rejlik

Amikor az emberek azt kérdezik, hol vannak az adataik, gyakran egyszerre több dologra is gondolnak. Ha ezeket a kérdéseket szétválasztjuk, a beszerzési tárgyalás kevésbé lesz teátrális és sokkal hasznosabb.

1. Hol vannak a bitek? Ez a fizikai és logikai tárolás kérdése. Ide tartoznak az elsődleges adatok, a replikák, a biztonsági mentések, a gyorsítótárak, az indexek és a releváns naplók. A kielégítő válasz megnevezi a kört, és azt, hogy milyen feltételek mellett változik a válasz.

2. Hol történik a feldolgozás? Egy rekordot tárolhatnak az egyik joghatóságban, miközben máshol alakítják át, keresik, osztályozzák, titkosítják vagy fejtik meg. A feldolgozás lehet ütemezett feladat, támogatási művelet, megfigyelési folyamat vagy helyreállítás során készült ideiglenes másolat.

3. Ki érheti el? Ez a személyazonossági és működési kérdés. Ide tartoznak a munkatársak, a rendszergazdák, a vállalkozók, a szolgáltatásfiókok, az incidenskezelők és az automatizált rendszerek. Az embernek nem kell a szerver mellett laknia ahhoz, hogy tényleges hozzáférése legyen hozzá.

4. Ki kényszerítheti ki ezt a hozzáférést? Ez a joghatósági és jogi felhatalmazási kérdés. Az érintett szervezeteket és személyeket, az általuk betöltött szerepeket, az általuk aláírt szerződéseket és az őket kötelező jogi kötelezettségeket követi. Erre nem ad választ egy térképpont önmagában.

5. Mit tehet az ügyfél, ha a válasz megváltozik? Ez az ellenőrzés és a kilépés kérdése. Korlátozhatja-e az ügyfél a hozzáférést, forgathatja-e a kulcsokat, szerezhet-e megbízható nyilvántartást, állíthatja-e helyre a szolgáltatást, helyezheti-e át az adatokat, és szüntetheti-e meg a kapcsolatot anélkül, hogy elveszítené azt, amit védeni próbált?

Ezek a kérdések átfedik egymást, de nem felcserélhetők. Egy szolgáltató meggyőzően válaszolhat az elsőre, miközben a harmadikra gyengén. Egy szerződés papíron megválaszolhatja az ötödiket, miközben a technikai csapat soha nem futtatta le a kilépést. Egy helyi leányvállalat megválaszolhatja a vállalati személyazonosságra vonatkozó kérdést, miközben a szolgáltatás az anyavállalat infrastruktúrájától vagy támogatási szervezetétől függ. A helyes válasz nem az, hogy a legmegnyugtatóbb választ választjuk. Hanem az, hogy a teljes halmazt megtartjuk.

Ez az oka annak is, hogy a szuverenitásértékelések összezavarodhatnak. A szónak egyszerre kell lefednie a fizikai elhelyezkedést, a jogi függetlenséget, a működési kompetenciát, a gazdasági tulajdont, a stratégiai autonómiát és a távozás képességét. Ezek rokon törekvések. Nem egyetlen tulajdonság. Egy precíz intézmény megmondja, melyik tulajdonságra van szüksége, és milyen bizonyíték mutatná, hogy az létezik.

A joghatóság a felhatalmazást követi

A joghatóság nem egy misztikus felhő, amely egy ország körül lebeg. Ez egy módja annak, hogy leírjuk, mely jogi hatóságok szabályozhatják, rendelhetik el, vizsgálhatják, felülvizsgálhatják vagy orvosolhatják az érintett szereplők magatartását. Egy elosztott szolgáltatásban a szereplők ugyanolyan fontosak, mint a helyek. Egy vállalat bejegyezhető az egyik tagállamban, működtethet létesítményeket egy másikban, használhat támogató csapatot egy harmadikban, és függhet egy olyan anyavállalattól vagy alvállalkozótól, amelyre másutt vonatkoznak kötelezettségek. Az ügyfélnek, aki meg akarja érteni a jogi hatókört, a felhatalmazási láncot kell követnie, nem pedig a legközelebbi épületnél megállnia.

Ez nem jelenti azt, hogy minden külföldi kapcsolat meghiúsítja az európai ellenőrzést. Az európai szolgáltatások tervezetten összekapcsoltak. A határokon átnyúló kereskedelem, kutatás, támogatás, finanszírozás és infrastruktúra normális. A kérdés az, hogy az intézmény tudja-e, melyik kapcsolat milyen hatalmat hordoz. Egy európai üzemeltető visszautasíthat egy hétköznapi kérést, de nem rendelkezhet felhatalmazással egy másik szervezet kötelező utasításának ellenállni. Egy alvállalkozó rendelkezhet olyan hitelesítő adattal, amelyet a fővállalkozó nem vett fel a saját hozzáférési leltárába. Egy támogatási folyamat lehetővé teheti a távoli hozzáférést akkor is, ha a tárolási szerződés helyi régiót ígér.

A jogi elemzés attól is függ, hogy milyen jellegű adatról és milyen jellegű kérésről van szó. A személyes adatok esetében előtérbe kerülnek a GDPR átviteli szabályai és az alapjogi keret. A nem személyes adatok nem jogi vákuumban léteznek. A Data Act védelmi rendelkezéseket tartalmaz a harmadik országbeli hatóságoknak az Unióban tárolt nem személyes adatokra vonatkozó egyes kéréseire. Egy kérést a rendelet feltételei szerint kell megvizsgálni, beleértve a kérés jellegét és a harmadik ország jogrendszerében elérhető védelmet. A két szabályozási rendszer különbözik, és pontosan ez a különbség az oka annak, hogy a vevőnek nem szabad összemosnia őket a rezidencia szóban.

A Bíróság C-311/18. sz. ügyben hozott ítélete hasznos európai jogi mintát kínál. A Bíróság nem azt vizsgálta, hogy a szerződés formailag kellően szabályos-e. Hanem azt, hogy az európai jog által garantált védelem lényegében egyenértékű maradna-e az átvitel körülményei között, figyelembe véve az adatokat érintő jogszabályokat és gyakorlatot. A standard szerződési kikötések kötelezik az aláíró feleket. Nem kötelezik azonban azokat a hatóságokat, amelyek nem részesei a szerződésnek. Ha a jogi környezet aláássa a megígért védelmet, az adatkivitelnek reagálnia kell.

Ez a logika túlmutat az adott jogvitán. A szerződés a magánjogi elosztás eszköze. A joghatóság az a tér, amelyben a közhatalom gyakorolható. A szerződés meghatározhatja, hogy a szállító mit ígért az ügyfélnek. Önmagában azonban nem szüntetheti meg azt a közhatalmi jogosítványt, amely a szállítót vagy annak munkatársait köti. A jó kormányzás mindkét állítást komolyan veszi. Szerződésekkel határozza meg a kötelezettségeket, technikai intézkedésekkel pedig teszi ezeket a kötelezettségeket megfigyelhetővé, miközben elismeri, hogy a jogi hatókör megváltoztathatja a rendelkezésre álló lehetőségeket.

Csábító, hogy ebből egyetlen veszélyes ország felkutatását csináljuk. Ez kevésbé hasznos, mint a tényleges hatóságok feltérképezése. Melyik szervezet az adatkezelő vagy az adatfeldolgozó? Melyik szervezet foglalkoztatja a rendszergazdát? Melyik szervezet birtokolja a titkosítási kulcsokat? Melyik szervezet tud másolatot készíteni? Melyik szervezet kapja a támogatási kérést? Melyik hatóság adhat ki utasítást? Milyen jogorvoslati lehetősége lenne az ügyfélnek, és melyik fórum előtt? A térkép megnyugtató lehet. Lehet, hogy nem az. Bármelyik eredmény értékesebb, mint egy országmatrica.

A tulajdonjog cím, nem kulcs

A tulajdonjognak valódi jogi és gazdasági ereje van. Meghatározhatja, hogy ki adhat el egy eszközt, ki nevezhet ki igazgatókat, ki engedélyezheti a szellemi tulajdont, ki kaphat bevételt, vagy ki hozhat bizonyos döntéseket. Köztestület esetén kapcsolódhat a nyilvántartásokért vagy az infrastruktúráért viselt törvényi felelősséghez. Vállalatcsoportban megmagyarázhatja, hogy ki szavazhat, ki egyesülhet, ki finanszírozhat vagy ki válthat le szolgáltatót. A tulajdonjognak helye van a szuverenitásértékelésben.

A tulajdonjog azonban nem jelent automatikusan üzemeltetési ellenőrzést. Az ügyfél lehet az adat tulajdonosa, miközben a szállító üzemelteti az adatbázist, kezeli a biztonsági mentési rendszert és ellenőrzi a szolgáltatásfiókot. Egy közintézmény lehet egy épület tulajdonosa, miközben a vállalkozó birtokolja a karbantartási hitelesítő adatokat és az egyetlen kipróbált módot a berendezés helyreállítására. Egy vállalat lehet a forráskód tulajdonosa, miközben egy harmadik fél ellenőrzi az aláíró kulcsot, a build futtatót, a csomagregisztert és a telepítési azonosítót. A cím valós. A függőség is az.

A különbség az igékben válik láthatóvá. A tulajdonjog főnév a szerződésben. Az ellenőrzés azt a képességet jelenti, hogy valaki megvizsgálhat, üzemeltethet, módosíthat, leállíthat, helyreállíthat, exportálhat, törölhet és igazolhat. Egy beszerzési eljárás, amely csak főneveket rögzít, hagyhatja a fontos igéket hozzárendelés nélkül. Lehet, hogy van megnevezett tulajdonosa a platformnak, de nincs megnevezett személy, aki kulcsot forgathat, kiemelt jogosultságú fiókot távolíthat el, vagy biztonsági mentésből állíthatja helyre anélkül, hogy olyan szervezethez fordulna, amely nincs a teremben.

Nincs erény abban, ha maximális birtoklást követelünk. Egy kórháznak, egyetemnek vagy önkormányzatnak lehet, hogy nincs meg a személyzete és biztonsági képessége ahhoz, hogy minden réteget biztonságosan üzemeltessen. Egy feladat kiszervezése felelős döntés lehet, ha a határok egyértelműek, és az ügyfél megőrzi a felügyelet, tesztelés és helyreállítás képességét. A lényeg nem az, hogy minden szervert egy nyilvános pincébe helyezzünk. A lényeg az, hogy eldöntsük, mely jogosultságok elengedhetetlenek a küldetéshez, és azokat elég közel tartsuk ahhoz, hogy irányítani tudjuk őket.

Ehhez a döntéshez bizonyítékokra van szükség. Az „az ügyfél tulajdonolja az adatokat” kijelentésnek kérdéseket kell kiváltania az exportformátumról, a kulcsok őrzéséről, a megőrzésről, a törlésről, a hozzáférési naplókról és a támogatási jogosultságokról. A „a szolgáltató európai” kijelentésnek kérdéseket kell kiváltania a vállalati irányításról, az alvállalkozókról, az infrastruktúráról, a jogi kitettségről és a folytonosságról. A „az adatok az Unióban vannak” kijelentésnek kérdéseket kell kiváltania a távoli adminisztrációról, a replikákról, a feldolgozási helyekről és a jogi megkeresésekről. Egy jó válasz bonyolult lehet. A bonyolultság nem hiba, ha a rendszer maga bonyolult.

Az üzemeltetési irányítás a cselekvés joga

Az üzemeltetési irányítást a legkönnyebb egy cselekvésen keresztül megérteni, nem pedig egy jelzőn keresztül. Vegyünk egy ügyfelet, akinek vissza kell vonnia egy rendszergazda jogosultságát. Ki hajthatja végre a visszavonást? Melyik identitásrendszer engedélyezi? A szolgáltatónak kell végrehajtania a módosítást, vagy az ügyfél megteheti közvetlenül? A művelet kiterjed-e a támogatási fiókokra, a vészhelyzeti fiókokra és a tétlen hitelesítő adatokra? Van-e feljegyzés, amely igazolja, hogy mikor tűnt el a jogosultság? Ha egy művelet ügyfélszolgálattól függ, akkor az ügyfélszolgálat része az irányítási síknak.

Ugyanez a teszt vonatkozik a kulcsokra is. A titkosítás csökkentheti a kitettséget, de az irányítása attól függ, hogy ki hozza létre, tárolja, forgatja, állítja helyre és használhatja a kulcsokat. Egy helyben tárolt rekord olvashatatlan maradhat egy olyan fél számára, amely nem jut hozzá a kulcshoz. Ugyanakkor hozzáférhetetlenné is válhat az ügyfél számára, ha az egyetlen helyreállítási út egy beszállítónál van. A kulcsok őrzése ezért sem nem szlogen a szuverenitásról, sem nem varázstörlő a joghatóság tekintetében. Ez egy konkrét irányítási elem, amelyet hozzá kell rendelni és gyakorolni kell.

A naplók ugyanezt a bánásmódot érdemlik. Egy műszerfal mutathatja a tevékenységet. A bizonyítékhoz olyan feljegyzés kell, amelyet az ügyfél megőrizhet, értelmezhet és vitathat. Ki írja a naplót? Megváltoztathatja-e egy rendszergazda? Megbízható-e az időforrás? Kiterjed-e a támogatási hozzáférésre és az automatizált feldolgozásra? Hozzájuthat-e az ügyfél használható exporthoz a szolgáltató engedélye nélkül? Mi történik, ha a fiókot lezárják? Egy napló, amely eltűnik a szolgáltatással együtt, hasznos az üzemeltetéshez, de gyenge az elszámoltathatósághoz.

A helyreállítás a legnehezebb üzemeltetési irányítási teszt, mert minden függőséget láthatóvá tesz. Egy szolgáltató ígérhet biztonsági mentést, mégis a visszaállításhoz szükség lehet egy adott régióra, egy elérhetetlen licencre, egy mérnökre, aki már nem ott dolgozik, vagy egy külön rendszerben tárolt titokra. Az ügyfél birtokolhatja a biztonsági mentési fájlt, és mégis képtelen lehet működő szolgáltatássá alakítani. A helyreállítást egész cselekvésként kell tesztelni, az eredményt rögzíteni kell, a hiányosságokat pedig olyan emberekhez kell rendelni, akik be tudják zárni azokat.

A szolgáltatás leállítása szintén irányítás. Egy intézménynek szüksége lehet arra, hogy szüneteltessen egy integrációt, elkülönítsen egy adatkészletet, felfüggesszen egy automatizált feldolgozást, vagy megakadályozzon egy új replika létrehozását. Ha csak egy szállító tudja végrehajtani a leállítást, akkor a szállító személyazonossága, jogi kötelezettségei, válaszideje és támogatási folyamata az intézmény kockázatának részévé válik. Ez elfogadható megállapodás lehet. De nem láthatatlan.

Ezeknek a teszteknek nem az a célja, hogy minden szállítóban bizalmatlankodjunk. A cél az, hogy a bizalmat egy ellenőrizhető kapcsolatra cseréljük. Egy szállító, amelyik egyértelmű választ ad, el tudja magyarázni, mely műveleteket hajt végre ő, melyeket az ügyfél, és melyek igényelnek együttműködést. Egy szállító, amelyik egyetlen megnyugtató mondatra támaszkodik, még nem válaszolt az üzemeltetési kérdésre.

Az alvállalkozók egy válaszból láncot csinálnak

Egy szolgáltatás ritkán egyetlen szervezet, amely egyetlen helyen végez egyetlen dolgot. A felhőszolgáltatók speciális infrastruktúrát, támogató partnereket, megfigyelő szolgáltatásokat, biztonsági műveleteket, hardverkarbantartást, hálózati szolgáltatókat és más beszállítókat vesznek igénybe. Egyesek szerepelnek a szerződésben. Mások alvállalkozói listán, szolgáltatásleírásban, incidensbejelentésben vagy támogatási munkafolyamatban jelennek meg. A lánc hétköznapi. A lánc megértésére vonatkozó kötelezettség is hétköznapi.

Az ENISA kockázatértékelése egy ismerős hibára hívja fel a figyelmet: a felhőszolgáltató olyan harmadik félnek adhat alvállalkozásba szolgáltatásokat, amely nem nyújt ugyanazokat a garanciákat, miközben az irányítás változása módosíthatja a szolgáltató feltételeit. A jelentés nem modern architektúraspecifikáció, és nem is kell annak lennie. Tartós figyelmeztetése szervezeti jellegű. Az ügyfél nem állíthatja, hogy érti a szolgáltatást, ha csak a számlán szereplő első céget mérte fel.

Az EDPB ajánlásai konkrétabbak a személyes adatok tekintetében. Az első lépés az adattovábbítások ismerete, beleértve a feldolgozók és alvállalkozók felé történő továbbításokat is. A harmadik országból történő távoli hozzáférés önmagában is adattovábbításnak minősülhet, még akkor is, ha a nyilvántartás egy EGT-adatközpontban marad. A támogatási megállapodás ezért az adattovábbítási térkép része, nem pedig lábjegyzet, amelyet az üzembe helyezés után lehet kezelni.

Az alvállalkozók láthatósága nem ugyanaz, mint az alvállalkozók feletti ellenőrzés. A lista megmondja az ügyfélnek, hogy ki vesz részt a folyamatban. Az ellenőrzés azt kérdezi, hogy az egyes felek mit tehetnek, milyen adatokhoz férhetnek hozzá, milyen jogi eszköz fedi le a tevékenységet, hogyan történik a változás bejelentése, és milyen jogorvoslat létezik, ha a fél már nem teljesíti a feltételeket. A láncnak határokkal és bizonyítékokkal kell rendelkeznie minden átadási ponton.

Gyakorlati ok is szól a homályos láncok elkerülése mellett. Amikor incidens történik, a felelősség gyakran az adatokkal ellentétes irányba halad. Az ügyfél a szolgáltatóhoz fordul. A szolgáltató egy platformcsapathoz fordul. A platformcsapat egy szakbeszállítóhoz fordul. A szakbeszállító egy másik szervezet rendszergazdájához fordul. Minden egyes átadás késedelmet, bizonytalanságot és lehetőséget adhat arra, hogy az eredeti nyilvántartás elveszítse a kontextust. Az ellenőrzési térképnek az incidens előtt kell megmutatnia az útvonalat, amíg az érintett embereknek még van idejük pontosnak lenni.

Személyes adatok: a védelem a nyilvántartással együtt utazik

A GDPR nem azzal teszi biztonságossá a személyes adatokat, hogy európai ajtó mögé zárja őket. Az átvitelre vonatkozó szabályai azt a célt szolgálják, hogy az adatok harmadik országba történő továbbítása esetén is magas szintű védelemben részesüljenek. Az EDPB világosan megfogalmazza az elvet: az adatokkal lényegében azonos szintű védelemnek kell kísérnie azokat, bárhová is kerülnek, az átvitel során és azt követően is.

Ez nem jelenti azt, hogy minden átvitel tilos. A GDPR különböző átviteli eszközöket és feltételeket kínál, beleértve a megfelelőségi határozatokat és a 46. cikk szerinti garanciákat. A jogi kérdés az, hogy a választott eszköz az adott körülmények között működik-e. Az EDPB ajánlásai arra kérik az adatkezelőket, hogy értékeljék az adott átvitelre vonatkozó jogszabályokat és gyakorlatot, vegyék figyelembe, hogy az adatimportőr vagy az adat a problémás szabályok hatálya alá eshet-e, és dokumentálják az indoklást. Ha semmilyen kiegészítő intézkedés nem állítja helyre a megkövetelt védelmi szintet, az átvitelt el kell kerülni, fel kell függeszteni vagy meg kell szüntetni.

Három részletet különösen könnyű figyelmen kívül hagyni egy adatkezelési helyszínről szóló beszélgetésben. Először is, a továbbítás számít. Egy szolgáltató az elsődleges nyilvántartást az EGT-ben tarthatja, és egy másolatot küldhet egy támogatási vagy elemzési szolgáltatásnak máshová. Másodszor, a hozzáférés számít. Egy harmadik országban lévő rendszergazda hozzáférhet egy nyilvántartáshoz anélkül, hogy a nyilvántartás fizikailag az illető asztalára kerülne. Harmadszor, az elszámoltathatóság számít. Az adatkezelőnek képesnek kell lennie az értékelés bemutatására, és azt felül kell vizsgálnia, ha a szolgáltatás, a jogszabály, az érintett személyek vagy a körülmények változnak.

A keretrendszer ezért megköveteli az ügyféltől, hogy megértse mind a technikai utat, mind a jogi kontextust. A régiókat és nyilakat ábrázoló diagram hasznos. Nem helyettesítheti az átviteli értékelést. Az sem helyettesíti, ha a szolgáltató szerződésben vállalja a megfelelést, amennyiben az ügyfél nem ellenőrizte, hogy a releváns garanciák mit érnek el azokkal a jogszabályokkal és gyakorlatokkal szemben, amelyek a szolgáltatóra vonatkozhatnak.

Az európai adatvédelmi jog egészséges bizalmatlansággal viseltetik a varázsszavak iránt. Az „EU-s tárhely” leírhat egy hasznos tényt. A „megfelelő” leírhat egy olyan következtetést, amely indoklást igényel. A „szuverén” leírhat egy politikai célt. Egyik sem helyettesítheti az arra vonatkozó bizonyítékot, hogy az adatok védettek, a hozzáférés szabályozott, és a döntés megvédhető.

Nem személyes adatok: más szabályozás, ugyanaz a fegyelem

A Data Act az adatkapcsolatok szélesebb körével foglalkozik, és szabályokat tartalmaz az adatfeldolgozó szolgáltatásokra, például a felhő- és edge szolgáltatásokra vonatkozóan. Nem helyettesíti a GDPR-t, és nem változtat minden felhővel kapcsolatos döntést adatvédelmi átviteli értékeléssé. Viszont egy második európai emlékeztetőt ad arra, hogy a helyszínt, a hozzáférést, a szolgáltatóváltást és a hatáskört együtt kell figyelembe venni.

A nem személyes adatok Unión belüli tárolása esetén a Bizottság Data Acthez fűzött magyarázata ismerteti a harmadik országbeli hatóság bizonyos kérelmeire vagy döntéseire vonatkozó garanciákat. Ha a hozzáférést nem szabályozza alkalmazandó nemzetközi megállapodás, a rendelet olyan feltételeket határoz meg, amelyek az európai érdekek védelmét szolgálják, beleértve a harmadik ország jogrendszerének és a kérelem arányosságának vizsgálatát. A szolgáltatóknak észszerű intézkedéseket kell tenniük, például titkosítást, auditokat vagy tanúsítási eljárásokat kell alkalmazniuk a jogosulatlan hozzáférés megakadályozására, és lehetőség szerint tájékoztatniuk kell az ügyfeleket.

A megfogalmazás számít. A Data Act nem állítja, hogy az Unió eltüntetheti a külföldi jogrendszereket. Keretet hoz létre bizonyos hozzáférési utak értékelésére és korlátozására. A szolgáltatónak továbbra is tudnia kell, hogy milyen rendszereket üzemeltet, milyen adatokat tárol, ki válaszolhat egy kérelemre, és milyen bizonyítékokat tud az ügyfélnek adni. Az ügyfélnek továbbra is meg kell értenie, hogy az adatok mely részei személyesek, melyek nem, és mely egyéb jogi szabályozások vonatkoznak rájuk.

A törvény a váltást is szabályozza. Az ügyfeleknek lehetőségük kell legyen az adatfeldolgozási szolgáltatások közötti átállásra, a szolgáltatások párhuzamos használatára, valamint az exportálható adatok és digitális eszközök átvitelére. A szolgáltatóknak tájékoztatást kell adniuk az exportformátumokról, a felületekről, az ismert korlátokról és a folyamat időtartamáról. A funkcionális egyenértékűségre vonatkozó szabályok egy gyakorlati igazságot ismernek el: egy letölthető fájl nem feltétlenül jelent helyreállítható szolgáltatást.

A váltást gyakran versenyjogi intézkedésként említik, és valóban az is. Ugyanakkor operatív értelemben szuverenitási intézkedés is. Az az intézmény, amelyik el tud menni, nagyobb teret kap arra, hogy visszautasítson egy számára elfogadhatatlan változást. Az az intézmény, amelyik nem tud elmenni, lehet, hogy rendelkezik szerződéssel, mégis a szolgáltató alapértelmezései irányítják. A váltáshoz való jogi lehetőség fontos kezdet. A begyakorolt migráció, amely megőrzi az adatokat, a konfigurációt és a bizonyítékokat, az a rész, amely a jogot valóban használhatóvá teszi.

Szerződések, kulcsok és a megnyugtatás korlátai

A szerződések továbbra is alapvetőek. Felosztják a kötelezettségeket, értesítési szabályokat határoznak meg, azonosítják az alvállalkozó feldolgozókat, meghatározzák a megengedett feldolgozást, leírják a törlést és a megőrzést, auditjogokat hoznak létre, és segítséget írnak elő az átállás idejére. Az adatmegosztási rendelet felhőszolgáltatás-váltásra vonatkozó rendelkezései megerősítik a világos szerződéses feltételek, az exportálható adatok és a kilépés mechanikájára vonatkozó tájékoztatás iránti igényt. Az ENISA korábbi iránymutatása szintén azt javasolja, hogy a felhőszolgáltatási szerződések értékelésekor fordítsanak figyelmet az adattovábbításra, az irányításváltozásra, a bűnüldözési hozzáférésre, az adatszivárgás-bejelentésekre és a felelősségre.

A szerződés nem futásidőben érvényesülő vezérlés. Egy olyan kikötés, amely szerint az ügyfél exportálhat, gyengébb, mint egy reprezentatív adathalmazon végrehajtott és egy második környezetben visszaállított exportteszt. Egy olyan kikötés, amely szerint a szolgáltató töröl, gyengébb, mint egy ellenőrizhető törlési folyamat, amely kiterjed a replikákra, a gyorsítótárakra, a biztonsági mentésekre és a származtatott rekordokra. Egy auditjogot biztosító kikötés gyengébb, mint azok a naplók és bizonyítékok, amelyeket az ügyfél ténylegesen meg tud szerezni. A papír számít. A papír, amely soha nem találkozik egy működő rendszerrel, udvariasan megfogalmazott optimizmus.

A kulcsok hasonló tanulsággal szolgálnak. Az ügyfél által ellenőrzött titkosítás csökkentheti, hogy a szolgáltató vagy egy jogosulatlan fél mit tud elolvasni. Nem ad választ arra, hogy ki kényszerítheti ki a helyreállítási kulcs birtokosától az együttműködést, ki irányítja a hardveres biztonsági modult, ki módosíthatja a kulcskezelési szabályzatot, vagy mi történik, ha az ügyfél elveszíti a saját hitelesítő adatát. A jól megtervezett megoldás használhat megosztott jogosultságot, független letétkezelést, gondosan korlátozott hozzáférést és tesztelt helyreállítást. A rossz megoldás más joghatóságba helyezheti a döntő kulcsot, és azért nevezi a megoldást helyinek, mert az adatbázis helyi.

A jogi és technikai intézkedéseket együtt kell megtervezni. Ha a szerződés megköveteli, hogy az ügyfél jóváhagyja a támogatási hozzáférést, a szolgáltatásnak rendelkeznie kell egy nyomot hagyó jóváhagyási folyamattal. Ha az ügyfélnek meg kell akadályoznia a továbbítást, a szolgáltatónak fel kell tárnia az útvonalat és érvényesítenie kell a határt. Ha egy hatósági megkeresést értékelni kell, az incidenskezelési folyamatnak meg kell őriznie a megkeresést, a jogi elemzést, a döntést, az értesítést és a választ. Egy jogi ígéret akkor válik hitelessé, ha egy rendszer meg tudja mutatni, hogyan hajtják végre.

Ugyanez az elv vonatkozik a tulajdonosváltásra is. Egy beszállító felvásárlása, egy új anyavállalat, egy alvállalkozó változása vagy a szolgáltatás működési régiójának megváltozása átalakíthatja az ellenőrzési térképet anélkül, hogy az ügyfél felé megjelenő márka változna. A szerződéseknek értesítési és jogorvoslati kötelezettséget kell előírniuk. A műszaki leltárakat frissíteni kell. Egy változásnaplónak meg kell mutatnia, mely jogosultságok kerültek át. Az a kormányzás, amely csak az aláíráskor létezik, rövid felezési idővel rendelkezik.

A vevő ellenőrzési térképe

Egy köz- vagy magánvevőnek nincs szüksége varázslatos kérdőívre. Olyan térképre van szüksége, amely összeköti az állításokat a bizonyítékokkal. Az alábbi kérdések jó kiindulópontot jelentenek, mert cselekvésekre, szereplőkre és nyilvántartásokra kérdeznek rá, nem pedig egy előnyben részesített jelzőre.

A táblázat szándékosan prózai. Túl kell élnie a beszerzési csapattal való kapcsolatfelvételt. Emellett lehetőséget ad a vevőnek a szolgáltatók összehasonlítására anélkül, hogy azt állítaná, hogy egy tanúsítvány, egy nemzeti zászló vagy egy adatközpont-látogatás mindent eldönt. A bizonyítékok bizalmasak lehetnek. A bizonyítékokra vonatkozó követelménynek nem szabad annak lennie.

Kérjen bemutatót a kritikus műveletről, ne csak leírást. Mutassa meg, hogyan távolítanak el egy privilegizált fiókot. Mutassa meg, hogyan hagynak jóvá egy támogatási munkamenetet. Mutassa meg, mit kap az ügyfél, amikor exportot kér. Mutassa meg, hogyan találják meg a replikát. Mutassa meg, mit tesz egy jogi megkeresés az incidens-munkafolyamattal. Mutassa meg, hogyan működik tovább a szervezet, ha a szolgáltatói fiókot felfüggesztik. A cél nem az, hogy drámai hibát rendezzenek. Az a cél, hogy lássuk, létezik-e az ellenőrzés a prezentáción kívül is.

Ezután kérdezze meg, ki a felelős az eredményért. A teszt tulajdonos nélkül csak előadás. A hiányosság dátum nélkül állandó jellemző. Az ellenőrzés nyilvántartás nélkül csak meggyőződés. A térképnek ezért meg kell neveznie azt a személyt vagy testületet, aki vállalja a kockázatot, a szállítót, akinek a műveletet végre kell hajtania, és az utat az eredmény megkérdőjelezésére. Az irányítás nem kérdések halmaza. Döntések sorozata, amelyeknek van hová menniük.

Gondolatkísérlet egy európai archívumról

A következő címkézett hipotetikus eset, nem pedig egy tényleges ügyfélről vagy incidensről szóló jelentés. Képzeljen el egy városi archívumot, amely digitális tervdokumentumokhoz választ tárhelyszolgáltatást. A pályázat elsődleges tárolást követel meg az Európai Unióban, és titkosítást, biztonsági mentéseket és támogatási szolgálatot kér. Három szolgáltató felel meg a feltételeknek. Az egyik helyi bejegyzésű, de az Unión kívüli támogatási alvállalkozóra támaszkodik. Az egyik az Unióban tartja a tárolást és a támogatást, de a szülővállalat identitásplatformját használja. Az egyik kisebb helyi működéssel, egyértelmű kulcskezeléssel és tesztelt exporttal rendelkezik, de gondosan meghatározott szolgáltatási szintre van szüksége, mert nem tud minden opcionális funkciót kínálni.

Az első szolgáltató még elfogadható lehet. A második még elfogadható lehet. A harmadik még alkalmatlan lehet egy adott rendelkezésre állási követelményre. A gondolatkísérlet lényege, hogy az adathely önmagában nem dönthet közöttük. Az archívumnak meg kell kérdeznie, milyen támogatási hozzáférés lehetséges, ki készíthet másolatot, mely jogi személyek kaphatnak megbízást, hogyan kezelik a kulcsokat, mit mutatnak a naplók, és hogy a nyilvántartások visszaállíthatók-e máshol.

Suppose the archive decides that local storage is its most important condition. It can write that requirement into the contract. It should also define the objects covered by the condition, require notice of a change, and ask how a breach would be detected. Suppose it decides that remote support is allowed only for a documented incident. The service needs an approval path, time-limited credentials and a record that can be reviewed. Suppose it decides that the archive must be able to leave. The exit should be tested before the service becomes the only place anyone knows how to read the records.

Nothing in this hypothetical requires the archive to operate a data centre. It requires the archive to understand the powers it delegates. That is the difference between responsible outsourcing and a purchase that moves the risk into a room the buyer cannot enter.

What Europe can honestly mean by sovereign

European sovereignty in digital infrastructure should be described in terms that can survive an awkward question. It can mean that a European institution retains authority over critical decisions. It can mean that key dependencies are visible, constrained and recoverable. It can mean that legal rights are matched by technical capability. It can mean that a public buyer can switch, challenge, inspect and continue operating when a provider or a law changes the available path.

It should not mean that a service is automatically safe because its marketing address is European. Nor should it mean that every foreign connection is forbidden. Europe depends on cross-border systems, and a rule that pretends otherwise will be ignored or quietly circumvented. The mature position is more demanding: permit the dependencies that serve the mission, document them, reduce the ones that carry unacceptable power, and keep an exit for the ones that cannot be made trustworthy.

That position also gives European providers a fairer test. A local provider should not have to perform a flag ceremony to be taken seriously. It should be able to show what it operates, what it delegates, who can access it, what law may apply, how data is protected, and how a customer can leave. A global provider should face the same questions. The standard is control evidence, not origin theatre.

The word sovereignty becomes useful when it changes buying behaviour. A ministry can use procurement to reward a tested exit path. A hospital can require key arrangements that match its clinical duties. A university can make the provenance of research data visible. A regulator can ask for the state of a system at the time of a decision. A supplier can design its service so that customer authority is not a decorative paragraph. These are institutional actions, not a slogan contest.

A small note from us

At Dweve, our public analysis The Sovereignty Illusion: where control really sits, published on 29 June 2026, uses a similar discipline. It separates ownership, technology, capital, infrastructure and legal exposure instead of allowing a European label to stand for all five. This article is narrower. It follows the data-centre claim into the operational and legal layers that a buyer has to govern.

That is also how we prefer to describe our own work. A system should make its boundaries legible: what is local, what is delegated, what is recorded, what can be challenged and what can be changed. The useful claim is the one a reader can inspect. The rest is decoration, and Europe already has plenty of decorative infrastructure.

The legal argument starts after the address

A data centre's location is worth knowing. It can affect physical access, resilience, connectivity, applicable local rules and the design of a service. It can be the right first question. It is a poor final answer.

A végső válasznak össze kell kötnie a helyszínt a felelősséggel. Meg kell neveznie az üzemeltetőt, a szereplőket, a kulcsokat, az alvállalkozókat, a jogi eszközöket, a lehetséges megkereséseket, a bizonyítékokat és a kilépés módját. Személyes adatok esetén az európai védelmi szintnek lényegében egyenértékűnek kell maradnia az adatok továbbítása után is, és az exportőröknek az adott körülményeket kell értékelniük, nem pedig egy helyszínre vonatkozó állítást megismételniük. A nem személyes adatok esetében a Data Act szabályokat ad a külföldi hozzáférésre és a felhőszolgáltató váltására, ami ismét kézzelfoghatóvá teszi az ellenőrzést és a hordozhatóságot.

Nincs egyetlen európai szám, amely egy bonyolult szolgáltatást szuverénné tehetne. Van egy sor kérdés, teszt és nyilvántartás. Ez a sorozat lassabb, mint az „EU-ban üzemeltetett” felirat egy brosúrán. Ugyanakkor ez az a rész, amely akkor is hasznos marad, amikor a brosúra már elavult.

Amikor a vevő megkérdezi, hol vannak az adatok, válaszoljon pontosan a helyszínre. Ezután kérdezze meg, ki olvashatja el, ki rendelkezhet velük, kit lehet kötelezni, ki tudja bizonyítani, mi történt, és ki tud távozni. Egy európai adatközpont része lehet egy megbízható megoldásnak. Önmagában azonban nem lehet jogi érv.

Források

• Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, Európai Adatvédelmi Testület, végleges változat, 2021. június 18. A hivatkozott oldal tartalmazza a hivatalos PDF-et is.
• Case C-311/18, Data Protection Commissioner v Facebook Ireland and Schrems II, az Európai Unió Bírósága, ítélet, 2020. július 16., EUR-Lex.
• Regulation (EU) 2023/2854, the Data Act, Európai Parlament és Tanács, 2023. december 13., EUR-Lex.
• Data Act explained, Európai Bizottság, megjelent 2025-ben, megtekintve 2026. augusztus 5-én.
• Cloud Computing Risk Assessment és a hivatalos jelentés PDF-je, az Európai Uniós Kiberbiztonsági Ügynökség (ENISA), 2009.
• The Sovereignty Illusion: where control really sits, Dweve, 2026. június 29.