Centrum danych nie jest argumentem prawnym

Centrum danych nie jest argumentem prawnym

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.

Systemy chmurowe są zaprojektowane do przenoszenia pracy. Replikacja może poprawić dostępność. Druga lokalizacja może utrzymać usługę przy życiu, gdy pierwsza jest niedostępna. Lokalizacja brzegowa może zmniejszyć opóźnienia. Zespół ds. bezpieczeństwa może kierować logi do centralnego systemu analitycznego. To zwykłe decyzje inżynieryjne, a nie dowód niewłaściwego postępowania. Oznaczają jednak, że sformułowanie „przechowywane w Europie” wymaga doprecyzowania technicznego. Które dane, w jakim stanie, przez jaki okres, w ramach jakiej operacji?

Ocena ryzyka chmurowego ENISA, opublikowana po raz pierwszy w 2009 roku, pozostaje przydatna właśnie dlatego, że odmówiła traktowania geografii jako kompletnego mechanizmu kontroli. Identyfikuje ryzyka związane z przechowywaniem w wielu jurysdykcjach, niewystarczającą informacją o jurysdykcjach, utratą nadzoru, podwykonawstwem i zmianami w kontroli nad dostawcą. Dokument jest na tyle stary, że ma słabość do akronimów, których współczesne zespoły mogą nie podzielać, jednak problem organizacyjny nie zniknął. Jeśli klient nie widzi, gdzie dane są przetwarzane ani kto odpowiada za kolejne przekazanie, klient nie może podjąć wiarygodnej decyzji o ryzyku.

Rezydencja może być uzasadnionym wymogiem. Archiwum publiczne może potrzebować, aby rekordy pozostały w określonym obszarze prawnym. Służba zdrowia może potrzebować ustaleń dotyczących przetwarzania, które ograniczają, gdzie mogą trafiać wrażliwe dane. Konsorcjum badawcze może mieć zobowiązania związane z fundatorem lub umową o udostępnianie danych. Te wymagania powinny być zapisane jako warunki operacyjne, z metodą ich weryfikacji, a nie jako pojedyncza nazwa kraju, którą każdy może interpretować w sposób liberalny.

Istnieje również różnica między ograniczeniem a gwarancją. Wymaganie od dostawcy utrzymywania podstawowego magazynu w Unii Europejskiej ogranicza jedną klasę przepływu. Nie gwarantuje, że żadna osoba spoza Unii nie uzyska dostępu do rekordu, że żadne metadane nie opuszczą systemu ani że żadne zagraniczne zobowiązanie prawne nie dosięgnie dostawcy. Ograniczenie może być użyteczne bez bycia gwarancją. Pomylenie tych dwóch pojęć tworzy historię zgodności, która przechodzi przez serwerownię, ale nie wytrzymuje bliższego przyjrzenia się płaszczyźnie zarządzania.

Użyteczne pytanie o rezydencję nie brzmi po prostu „gdzie to jest?”. Brzmi: „które lokalizacje są możliwe dla każdego stanu tych danych i kto może spowodować zmianę tego stanu?”. Dostawca powinien umieć wyjaśnić odpowiedź w sposób, który inżynier może wdrożyć, a kupujący zweryfikować. Jeśli wyjaśnienie opiera się na nieudokumentowanym wyjątku, nawyku wsparcia lub obietnicy, że podwykonawcy dostawcy będą się prawdopodobnie odpowiednio zachowywać, twierdzenie o rezydencji nie jest jeszcze operacyjne.

Pięć pytań ukrytych w słowie gdzie

Gdy ludzie pytają, gdzie znajdują się ich dane, często mają na myśli kilka różnych rzeczy naraz. Rozdzielenie tych pytań sprawia, że rozmowa o zakupie staje się mniej teatralna, a bardziej użyteczna.

1. Gdzie są bity? To pytanie o fizyczne i logiczne przechowywanie. Obejmuje dane podstawowe, repliki, kopie zapasowe, pamięci podręczne, indeksy i istotne logi. Zadowalająca odpowiedź określa zakres oraz warunki, w jakich odpowiedź się zmienia.

2. Gdzie odbywa się przetwarzanie? Rekord może być przechowywany w jednej jurysdykcji, a przekształcany, wyszukiwany, klasyfikowany, szyfrowany lub deszyfrowany gdzie indziej. Przetwarzanie może być zaplanowanym zadaniem, działaniem wsparcia, potokiem monitorowania lub tymczasową kopią utworzoną podczas odzyskiwania.

3. Kto może do niego dotrzeć? To pytanie o tożsamość i kwestie operacyjne. Obejmuje pracowników, administratorów, wykonawców, konta usługowe, osoby reagujące na incydenty i systemy zautomatyzowane. Osoba nie musi mieszkać obok serwera, aby mieć do niego faktyczny dostęp.

4. Kto może wymusić ten dostęp? To pytanie o jurysdykcję i uprawnienia prawne. Dotyczy odpowiednich organizacji i osób, pełnionych przez nie ról, podpisywanych umów oraz obowiązków prawnych, które mogą je wiązać. Nie odpowiada na nie sama pinezka na mapie.

5. Co może zrobić klient, gdy odpowiedź się zmieni? To pytanie o kontrolę i wyjście. Czy klient może ograniczyć dostęp, obrócić klucze, uzyskać wiarygodny zapis, przywrócić usługę, przenieść dane i zakończyć relację bez utraty tego, co chciał chronić?

Te pytania nakładają się na siebie, ale nie są wymienne. Dostawca może przekonująco odpowiedzieć na pierwsze, a słabo na trzecie. Umowa może na papierze odpowiadać na piąte, podczas gdy zespół techniczny nigdy nie przeprowadził wyjścia. Lokalna spółka zależna może odpowiadać na pytanie o tożsamość korporacyjną, podczas gdy usługa zależy od infrastruktury lub organizacji wsparcia spółki macierzystej. Właściwa reakcja nie polega na wybraniu najbardziej pocieszającej odpowiedzi. Polega na zachowaniu całego zestawu.

To również powód, dla którego oceny suwerenności mogą być mylące. Słowo ma obejmować fizyczne miejsce zamieszkania, niezależność prawną, kompetencje operacyjne, własność ekonomiczną, autonomię strategiczną i zdolność do odejścia. To powiązane ambicje. Nie są jedną właściwością. Precyzyjna instytucja określa, której właściwości potrzebuje i jakie dowody świadczyłyby o jej istnieniu.

Jurysdykcja podąża za władzą

Jurysdykcja to nie mistyczna chmura otaczająca kraj. To sposób opisania, które organy prawne mogą regulować, nakazywać, badać, kontrolować lub naprawiać działania odpowiednich podmiotów. W usłudze rozproszonej podmioty mają znaczenie równie duże jak miejsca. Firma może być zarejestrowana w jednym państwie członkowskim, prowadzić obiekty w drugim, korzystać z zespołu wsparcia w trzecim i zależeć od spółki macierzystej lub podwykonawcy podlegającego obowiązkom gdzie indziej. Klient próbujący zrozumieć zasięg prawny musi podążać za łańcuchem władzy, a nie zatrzymywać się przy najbliższym budynku.

Nie oznacza to, że każde zagraniczne połączenie przekreśla europejską kontrolę. Usługi europejskie są z założenia wzajemnie połączone. Transgraniczny handel, badania, wsparcie, finansowanie i infrastruktura są normalne. Pytanie brzmi, czy instytucja wie, które połączenie niesie jaką władzę. Europejski operator może być w stanie odmówić zwykłemu żądaniu, ale nie mieć uprawnień, by sprzeciwić się wiążącemu poleceniu innej organizacji. Podwykonawca może posiadać poświadczenie, którego zleceniodawca nie uwzględnił we własnym rejestrze dostępu. Proces wsparcia może umożliwiać zdalny dostęp, nawet gdy umowa dotycząca przechowywania obiecuje lokalny region.

Analiza prawna zależy także od rodzaju danych i rodzaju żądania. Dane osobowe wprowadzają w grę zasady przekazywania danych wynikające z RODO oraz ramy praw podstawowych. Dane nieosobowe nie znajdują się w prawnej próżni. Akt o danych zawiera zabezpieczenia dotyczące niektórych żądań organów publicznych państw trzecich dotyczących danych nieosobowych przechowywanych w Unii. Żądanie należy rozpatrywać przez pryzmat warunków określonych w rozporządzeniu, w tym charakteru żądania i ochrony dostępnej w systemie prawnym państwa trzeciego. Te dwa reżimy różnią się od siebie i właśnie ta różnica sprawia, że nabywca nie powinien sprowadzać ich do słowa rezydencja.

Wyrok TSUE w sprawie C-311/18 stanowi użyteczny europejski wzorzec prawny. Trybunał nie pytał, czy umowa wygląda na wystarczająco formalną. Pytał, czy ochrona gwarantowana przez prawo europejskie pozostałaby w istocie równoważna w okolicznościach przekazania, z uwzględnieniem przepisów i praktyki, które mogłyby wpłynąć na dane. Standardowe klauzule umowne mogą wiązać strony, które je podpisują. Nie wiążą one organu publicznego, który nie jest stroną umowy. Jeżeli otoczenie prawne podważa obiecane zabezpieczenia, eksporter musi zareagować.

Ta logika wykracza poza konkretny spór. Umowa jest instrumentem prywatnej alokacji. Jurysdykcja to pole, na którym może działać władza publiczna. Umowa może określać, co dostawca obiecał klientowi. Nie może jednak sama w sobie usunąć uprawnienia publicznego, które wiąże dostawcę lub jego pracowników. Dobre zarządzanie traktuje oba te stwierdzenia poważnie. Wykorzystuje umowy do określenia obowiązków oraz środki techniczne do uczynienia tych obowiązków obserwowalnymi, uznając jednocześnie, że zasięg prawny może wciąż zmieniać dostępne opcje.

Kuszone jest przekształcenie tego w poszukiwanie jednego niebezpiecznego kraju. Jest to mniej użyteczne niż zmapowanie rzeczywistych organów. Który podmiot jest administratorem lub podmiotem przetwarzającym? Który podmiot zatrudnia administratora? Który podmiot posiada klucze szyfrujące? Który podmiot może sporządzić kopię? Który podmiot otrzymuje żądanie wsparcia? Który organ mógłby wydać nakaz? Jakie środki ochrony prawnej miałby klient i przed jakim forum? Mapa może być uspokajająca. Może też nie być. Każdy z tych wyników jest cenniejszy niż naklejka z nazwą kraju.

Własność to tytuł, nie klucz

Własność ma realną moc prawną i ekonomiczną. Może decydować o tym, kto może sprzedać składnik aktywów, powołać dyrektorów, udzielić licencji na własność intelektualną, otrzymywać przychody lub podejmować określone decyzje. W podmiocie publicznym może być związana z ustawową odpowiedzialnością za rejestry lub infrastrukturę. W grupie korporacyjnej może wyjaśniać, kto może głosować, łączyć się, finansować lub wymieniać dostawcę. Własność należy do oceny suwerenności.

Własność nie zapewnia automatycznie kontroli operacyjnej. Klient może być właścicielem danych, podczas gdy dostawca obsługuje bazę danych, zarządza systemem kopii zapasowych i kontroluje konto usługi. Instytucja publiczna może być właścicielem budynku, podczas gdy wykonawca posiada poświadczenia do konserwacji i jedyną przetestowaną drogę do przywrócenia sprzętu. Firma może być właścicielem kodu źródłowego, podczas gdy strona trzecia kontroluje klucz podpisywania, runner budowania, rejestr pakietów i tożsamość wdrożeniową. Tytuł jest realny. Realna jest też zależność.

Różnica staje się widoczna w czasownikach. Własność to rzeczownik w umowie. Kontrola to zdolność do przeglądania, obsługiwania, zmieniania, zatrzymywania, odzyskiwania, eksportowania, usuwania i udowadniania. Proces zakupowy, który rejestruje tylko rzeczowniki, może pozostawić ważne czasowniki bez przypisania. Może wskazywać właściciela platformy, a mimo to nie wskazywać osoby, która może obrócić klucz, usunąć uprzywilejowane konto lub przywrócić dane z kopii zapasowej bez pytania organizacji, której nie ma w pomieszczeniu.

Nie ma żadnej cnoty w żądaniu maksymalnego posiadania. Szpital, uczelnia czy gmina może nie mieć personelu i możliwości bezpieczeństwa, aby bezpiecznie prowadzić każdą warstwę. Zlecenie zadania może być odpowiedzialne, gdy granice są wyraźne, a klient zachowuje możliwość nadzorowania, testowania i odzyskiwania. Nie chodzi o to, aby umieścić każdy serwer w publicznej piwnicy. Chodzi o to, aby zdecydować, które uprawnienia są niezbędne dla misji, i utrzymać je na tyle blisko, aby można było nimi zarządzać.

Ta decyzja wymaga dowodów. „Klient jest właścicielem danych" powinno prowadzić do pytań o format eksportu, przechowywanie kluczy, retencję, usuwanie, dzienniki dostępu i uprawnienia wsparcia. „Dostawca jest europejski" powinno prowadzić do pytań o kontrolę korporacyjną, podwykonawców, infrastrukturę, ekspozycję prawną i ciągłość działania. „Dane są w Unii" powinno prowadzić do pytań o administrację zdalną, repliki, lokalizacje przetwarzania i żądania prawne. Dobra odpowiedź może być skomplikowana. Komplikacja nie jest wadą, gdy system jest skomplikowany.

Kontrola operacyjna to prawo do działania

Kontrolę operacyjną najłatwiej zrozumieć przez działanie, a nie przez przymiotnik. Rozważmy klienta, który musi odebrać uprawnienia administratorowi. Kto może dokonać odebrania uprawnień? Który system tożsamości to autoryzuje? Czy dostawca jest zobowiązany do wykonania zmiany, czy klient może zrobić to bezpośrednio? Czy działanie obejmuje konta wsparcia, konta awaryjne i uśpione poświadczenia? Czy istnieje zapis potwierdzający, kiedy uprawnienie zniknęło? Jeśli działanie zależy od helpdesku, helpdesk jest częścią płaszczyzny kontroli.

Ten sam test dotyczy kluczy. Szyfrowanie może zmniejszyć ekspozycję, ale jego zarządzanie zależy od tego, kto tworzy, przechowuje, rotuje, odzyskuje i może używać kluczy. Lokalnie przechowywany zapis może pozostać nieczytelny dla strony, która nie może uzyskać klucza. Może również stać się niedostępny dla klienta, gdy jedyna ścieżka odzyskiwania znajduje się u dostawcy. Przechowywanie kluczy nie jest zatem ani hasłem suwerenności, ani magiczną gumką do jurysdykcji. To konkretna kontrola, która musi być przypisana i przećwiczona.

Dzienniki zasługują na takie samo traktowanie. Pulpit nawigacyjny może pokazywać aktywność. Dowody wymagają zapisu, który klient może zachować, interpretować i kwestionować. Kto zapisuje dziennik? Czy administrator może go zmienić? Czy źródło czasu jest godne zaufania? Czy obejmuje dostęp wsparcia i przetwarzanie automatyczne? Czy klient może uzyskać użyteczny eksport bez zgody dostawcy? Co się dzieje, gdy konto jest zamykane? Dziennik, który znika wraz z usługą, jest użyteczny do operacji i słaby do rozliczalności.

Odzyskiwanie to najtrudniejszy test kontroli operacyjnej, ponieważ ujawnia każdą zależność. Dostawca może obiecywać kopie zapasowe, ale przywrócenie może wymagać konkretnego regionu, niedostępnej licencji, inżyniera, który już tam nie pracuje, lub sekretu przechowywanego w oddzielnym systemie. Klient może być właścicielem pliku kopii zapasowej i nadal nie mieć możliwości przekształcenia go w działającą usługę. Odzyskiwanie powinno być testowane jako całe działanie, z zapisanym wynikiem i przypisanymi lukami do osób, które mogą je zamknąć.

Zatrzymanie usługi to również kontrola. Instytucja może potrzebować wstrzymać integrację, wyizolować zbiór danych, zawiesić automatyczne przetwarzanie lub zapobiec utworzeniu nowej repliki. Jeśli tylko dostawca może wykonać zatrzymanie, tożsamość dostawcy, obowiązki prawne, czas reakcji i proces wsparcia stają się częścią ryzyka instytucji. Może to być akceptowalne rozwiązanie. Nie jest to jednak rozwiązanie niewidoczne.

Celem tych testów nie jest nieufność wobec każdego dostawcy. Chodzi o zastąpienie zaufania relacją, którą można zbadać. Dostawca z jasną odpowiedzią może wyjaśnić, które działania wykonuje sam, które wykonuje klient, a które wymagają współpracy. Dostawca, który opiera się na jednym uspokajającym zdaniu, nie odpowiedział jeszcze na pytanie operacyjne.

Podwykonawcy zamieniają jedną odpowiedź w łańcuch

Usługa rzadko oznacza jedną organizację wykonującą jedną rzecz w jednym miejscu. Dostawcy usług w chmurze korzystają z wyspecjalizowanej infrastruktury, partnerów wsparcia, usług monitorowania, operacji bezpieczeństwa, utrzymania sprzętu, operatorów sieci i innych dostawców. Niektórzy są widoczni w umowie. Inni pojawiają się na liście podprocesorów, w opisie usługi, w zgłoszeniu incydentu lub w procesie wsparcia. Łańcuch jest zwykłą praktyką. Obowiązek zrozumienia tego łańcucha również.

Ocena ryzyka ENISA wskazuje na znaną słabość: dostawca usług w chmurze może zlecić podwykonawstwo stronie trzeciej, która nie oferuje tych samych gwarancji, a zmiana kontroli może zmienić warunki dostawcy. Raport nie jest specyfikacją nowoczesnej architektury i nie musi nią być. Jego trwałe przesłanie ma charakter organizacyjny. Klient nie może twierdzić, że rozumie usługę, jeśli ocenił tylko pierwszą firmę wymienioną na fakturze.

Zalecenia EDPB są bardziej szczegółowe w odniesieniu do danych osobowych. Pierwszym krokiem jest poznanie transferów, w tym dalszych transferów do procesorów i podprocesorów. Zdalny dostęp z państwa trzeciego może sam w sobie stanowić transfer, nawet jeśli dane pozostają w centrum danych w EOG. Ustalenie dotyczące wsparcia jest zatem częścią mapy transferów danych, a nie przypisem, którym można się zająć po wdrożeniu.

Widoczność podwykonawcy to nie to samo co kontrola nad podwykonawcą. Lista informuje klienta, kto jest zaangażowany. Kontrola dotyczy tego, co każda strona może zrobić, jakie dane może zobaczyć, jakie narzędzie prawne obejmuje daną czynność, jak zgłaszana jest zmiana i jakie istnieją środki zaradcze, gdy strona przestaje spełniać warunki. Łańcuch powinien mieć granice i dowody na każdym etapie przekazania.

Istnieje praktyczny powód, aby unikać niejasnych łańcuchów. Gdy dochodzi do incydentu, odpowiedzialność często podąża w kierunku przeciwnym do danych. Klient pyta dostawcę. Dostawca pyta zespół platformy. Zespół platformy pyta wyspecjalizowanego dostawcę. Wyspecjalizowany dostawca pyta administratora w innej organizacji. Każde przekazanie może dodać opóźnienie, niepewność i okazję do utraty kontekstu oryginalnego rekordu. Mapa kontroli powinna pokazywać trasę przed incydentem, gdy zaangażowane osoby mają jeszcze czas na precyzję.

Dane osobowe: ochrona podąża za rekordem

RODO nie sprawia, że dane osobowe są bezpieczne tylko dlatego, że trafiają za europejskie drzwi. Jej przepisy o przekazywaniu danych mają na celu utrzymanie wysokiego poziomu ochrony, gdy dane trafiają do państwa trzeciego. EDPB opisuje tę zasadę wprost: zasadniczo równoważny poziom ochrony powinien towarzyszyć danym niezależnie od tego, dokąd trafią, zarówno w trakcie przekazywania, jak i po jego zakończeniu.

Nie oznacza to jednak, że każde przekazywanie jest zakazane. RODO przewiduje różne narzędzia i warunki przekazywania danych, w tym decyzje o stwierdzeniu odpowiedniego stopnia ochrony oraz zabezpieczenia na podstawie art. 46. Kwestia prawna sprowadza się do tego, czy wybrane narzędzie działa w danych okolicznościach. Zalecenia EDPB mówią administratorom, aby ocenili przepisy i praktykę istotne dla konkretnego przekazywania, rozważyli, czy odbiorca lub dane mogą podlegać problematycznym regulacjom, oraz udokumentowali swoje rozumowanie. Jeśli żaden środek uzupełniający nie przywróci wymaganego poziomu ochrony, przekazywania należy unikać, zawiesić je lub zakończyć.

Trzy szczegóły są szczególnie łatwe do przeoczenia w rozmowie o lokalizacji danych. Po pierwsze, znaczenie ma dalsze przekazywanie. Dostawca może przechowywać główny rekord w EOG i wysyłać jego kopię do serwisu wsparcia lub analitycznego gdzie indziej. Po drugie, znaczenie ma dostęp. Administrator w państwie trzecim może mieć możliwość odczytania rekordu bez fizycznego przenoszenia go na biurko tej osoby. Po trzecie, znaczenie ma odpowiedzialność. Administrator musi być w stanie wykazać przeprowadzenie oceny i ponownie ją przeprowadzić, gdy zmienią się usługa, przepisy, osoby lub okoliczności.

Te ramy wymagają zatem od klienta zrozumienia zarówno ścieżki technicznej, jak i kontekstu prawnego. Diagram regionów i strzałek jest pomocny, ale nie zastąpi oceny przekazywania danych. Nie zastąpi jej również umowne zapewnienie, że dostawca będzie przestrzegać przepisów, jeśli klient nie sprawdził, co istotne zabezpieczenia mogą osiągnąć wobec przepisów i praktyk, które mogą mieć zastosowanie do dostawcy.

Europejskie prawo ochrony danych słusznie nie ufa magicznym słowom. „Hosting w UE” może opisywać użyteczny fakt. „Zgodność” może opisywać wniosek, który wymaga uzasadnienia. „Suwerenność” może opisywać cel polityczny. Żadne z tych pojęć nie powinno zastępować dowodów na to, że dane są chronione, dostęp jest uregulowany, a decyzja może zostać obroniona.

Dane inne niż osobowe: inny reżim, ta sama dyscyplina

Akt w sprawie danych obejmuje szerszy zakres relacji dotyczących danych i zawiera przepisy dotyczące usług przetwarzania danych, takich jak usługi chmurowe i brzegowe. Nie zastępuje RODO i nie zamienia każdej decyzji dotyczącej chmury w ocenę przekazywania danych w ramach ochrony danych. Stanowi jednak drugie europejskie przypomnienie, że lokalizacja, dostęp, zmiana dostawcy i władza muszą być rozpatrywane łącznie.

W odniesieniu do danych innych niż osobowe przechowywanych w Unii wyjaśnienie Komisji dotyczące aktu w sprawie danych opisuje zabezpieczenia dotyczące niektórych żądań lub decyzji organów publicznych państw trzecich. W przypadku braku mającej zastosowanie umowy międzynarodowej regulującej dostęp rozporządzenie ustanawia warunki mające chronić interesy europejskie, w tym uwzględnienie systemu prawnego państwa trzeciego i proporcjonalności żądania. Dostawcy mają podejmować rozsądne środki, takie jak szyfrowanie, audyty lub ustalenia dotyczące certyfikacji, aby zapobiegać nieuprawnionemu dostępowi i informować klientów, gdy jest to możliwe.

Treść przepisów ma znaczenie. Akt w sprawie danych nie twierdzi, że Unia może sprawić, że obce systemy prawne znikną. Tworzy ramy oceny i ograniczania niektórych dróg dostępu. Dostawca nadal musi wiedzieć, jakie systemy obsługuje, jakie dane przechowuje, kto może odpowiedzieć na żądanie i jakie dowody można przedstawić klientowi. Klient nadal musi rozumieć, które części danych są danymi osobowymi, które nie są, oraz które inne reżimy prawne mają zastosowanie.

Ustawa podchodzi do kontroli również przez przełączanie. Klienci powinni mieć możliwość przechodzenia między usługami przetwarzania danych, korzystania z usług równolegle oraz eksportowania przenośnych danych i zasobów cyfrowych. Dostawcy muszą udzielać informacji o formatach eksportu, interfejsach, znanych ograniczeniach i czasie potrzebnym na ten proces. Przepisy dotyczące równoważności funkcjonalnej uznają praktyczną prawdę: plik, który można pobrać, niekoniecznie jest usługą, którą można odzyskać.

Przełączanie jest często opisywane jako środek konkurencji i rzeczywiście nim jest. Jest to również środek suwerenności w sensie operacyjnym. Instytucja, która może odejść, ma więcej swobody, by odrzucić zmianę, której nie może zaakceptować. Instytucja, która nie może odejść, może być właścicielem umowy, a mimo to podlegać domyślnym ustawieniom dostawcy. Prawo do przełączenia to ważny początek. Przećwiczona migracja, która zachowuje dane, konfigurację i dowody, to część, która czyni to prawo użytecznym.

Umowy, klucze i granice zapewnień

Umowy pozostają niezbędne. Przydzielają obowiązki, ustalają zasady powiadamiania, identyfikują podprocesorów, definiują dozwolone przetwarzanie, opisują usuwanie i przechowywanie, tworzą prawa do audytu oraz ustanawiają pomoc w trakcie przejścia. Przepisy aktu o danych dotyczące przełączania usług w chmurze wzmacniają potrzebę jasnych warunków umownych, możliwych do wyeksportowania danych oraz informacji o mechanice wyjścia. Wcześniejsze wytyczne ENISA również zalecają zwracanie uwagi na transfery danych, zmianę kontroli, dostęp organów ścigania, powiadomienia o naruszeniach i odpowiedzialność przy ocenie umów dotyczących chmury.

Umowa nie jest kontrolą w czasie rzeczywistym. Klauzula mówiąca, że klient może eksportować, jest słabsza niż eksport przeprowadzony na reprezentatywnym zbiorze danych i przywrócony w drugim środowisku. Klauzula mówiąca, że dostawca usunie dane, jest słabsza niż audytowalny proces usuwania obejmujący repliki, pamięci podręczne, kopie zapasowe i rekordy pochodne. Klauzula przyznająca prawo do audytu jest słabsza niż logi i dowody, które klient może faktycznie uzyskać. Dokumenty mają znaczenie. Dokumenty, które nigdy nie spotykają się z działającym systemem, są uprzejmie sformułowanym optymizmem.

Klucze dają podobną lekcję. Szyfrowanie kontrolowane przez klienta może ograniczyć to, co dostawca lub nieupoważniona strona może odczytać. Nie odpowiada jednak na pytanie, kto może zmusić osobę posiadającą klucz odzyskiwania, kto kontroluje moduł bezpieczeństwa sprzętowego, kto może zmienić politykę kluczy ani co się dzieje, gdy klient utraci własne poświadczenie. Właściwy projekt może wykorzystywać podział uprawnień, niezależne przechowywanie, starannie ograniczony dostęp i przetestowane odzyskiwanie. Niewłaściwy projekt może umieścić decydujący klucz w innej jurysdykcji i nazwać rozwiązanie lokalnym, ponieważ baza danych jest lokalna.

Środki prawne i techniczne powinny być projektowane razem. Jeśli umowa wymaga zatwierdzenia przez klienta dostępu wsparcia, usługa powinna mieć proces zatwierdzania pozostawiający ślad. Jeśli klient musi zapobiegać dalszym transferom, dostawca powinien ujawnić trasę i egzekwować granicę. Jeśli wniosek organu publicznego musi być oceniony, proces incydentowy powinien zachować wniosek, analizę prawną, decyzję, powiadomienie i odpowiedź. Obietnica prawna staje się wiarygodna, gdy system może pokazać, jak jest realizowana.

Ta sama zasada dotyczy zmian właścicielskich. Przejęcie dostawcy, nowa spółka dominująca, zmiana podwykonawcy lub zmiana regionu działania usługi mogą zmienić mapę kontroli bez zmiany marki widocznej dla klienta. Umowy powinny wymagać powiadomień i środków zaradczych. Inwentarze techniczne powinny być aktualizowane. Rejestr zmian powinien pokazywać, które uprawnienia się przesunęły. Zarządzanie, które istnieje tylko przy początkowym podpisaniu, ma krótki okres półtrwania.

Mapa kontroli nabywcy

Nabywca publiczny lub prywatny nie potrzebuje magicznego kwestionariusza. Potrzebuje mapy łączącej twierdzenia z dowodami. Poniższe pytania są dobrym punktem wyjścia, ponieważ pytają o działania, podmioty i rekordy, a nie o preferowany przymiotnik.

Tabela jest celowo prozaiczna. Ma przetrwać kontakt z zespołem zakupowym. Daje też kupującemu sposób porównania dostawców bez udawania, że certyfikat, flaga narodowa czy wycieczka po centrum danych rozstrzygają wszystko. Dowody mogą być poufne. Wymóg posiadania dowodów nie powinien być.

Poproś o demonstrację kluczowego działania, nie tylko o opis. Pokaż, jak usuwa się konto uprzywilejowane. Pokaż, jak zatwierdza się sesję wsparcia. Pokaż, co otrzymuje klient, gdy żąda eksportu. Pokaż, jak lokalizuje się replikę. Pokaż, co żądanie prawne robi z przepływem pracy przy incydencie. Pokaż, jak organizacja działa dalej, gdy konto dostawcy zostanie zawieszone. Nie chodzi o inscenizację spektakularnej awarii. Chodzi o to, aby sprawdzić, czy kontrola istnieje poza prezentacją.

Następnie zapytaj, kto jest właścicielem wyniku. Test bez właściciela to przedstawienie. Luka bez terminu to trwała cecha. Kontrola bez rejestru to przekonanie. Mapa powinna zatem wskazywać osobę lub organ, który akceptuje ryzyko, dostawcę, który musi wykonać działanie, oraz ścieżkę kwestionowania wyniku. Zarządzanie to nie stos pytań. To zestaw decyzji, które mają gdzie trafić.

Eksperyment myślowy o europejskim archiwum

Poniższe to oznaczona hipoteza, a nie raport o rzeczywistym kliencie lub incydencie. Wyobraź sobie archiwum miejskie wybierające usługę hostowaną dla zdigitalizowanych rejestrów planowania. Zamówienie wymaga podstawowego przechowywania w Unii Europejskiej i prosi o szyfrowanie, kopie zapasowe i biuro wsparcia. Trzej dostawcy spełniają te słowa. Jeden jest zarejestrowany lokalnie, ale polega na podwykonawcy wsparcia spoza Unii. Jeden utrzymuje przechowywanie i wsparcie w Unii, ale korzysta z platformy tożsamości firmy macierzystej. Jeden ma mniejszą lokalną operację, jasne przechowywanie kluczy i przetestowany eksport, ale potrzebuje starannie określonego poziomu usług, ponieważ nie może zaoferować każdej opcjonalnej funkcji.

Pierwszy dostawca może nadal być akceptowalny. Drugi może nadal być akceptowalny. Trzeci może nadal być nieodpowiedni dla konkretnego wymogu dostępności. Celem eksperymentu myślowego jest to, że samo miejsce zamieszkania nie może wybrać między nimi. Archiwum musi zapytać, jaki dostęp do wsparcia jest możliwy, kto może zrobić kopię, które podmioty prawne mogą otrzymać polecenie, jak zarządzane są klucze, co pokazują dzienniki i czy rejestry można odzyskać gdzie indziej.

Zakładając, że archiwum uzna, że lokalne przechowywanie danych jest jego najważniejszym warunkiem, może zapisać ten wymóg w umowie. Powinno też określić, jakie obiekty obejmuje ten warunek, wymagać powiadomienia o zmianie oraz zapytać, w jaki sposób wykrywane byłoby naruszenie. Zakładając, że uzna, iż zdalne wsparcie jest dozwolone wyłącznie w przypadku udokumentowanego incydentu, usługa potrzebuje ścieżki zatwierdzania, poświadczeń ograniczonych czasowo oraz rejestru, który można przejrzeć. Zakładając, że uzna, iż archiwum musi mieć możliwość odejścia, wyjście powinno zostać przetestowane, zanim usługa stanie się jedynym miejscem, w którym ktokolwiek wie, jak czytać zapisy.

Nic w tej hipotezie nie wymaga, aby archiwum prowadziło centrum danych. Wymaga natomiast, aby archiwum rozumiało uprawnienia, które deleguje. To jest różnica między odpowiedzialnym outsourcingiem a zakupem, który przenosi ryzyko do pomieszczenia, do którego kupujący nie ma wstępu.

Co Europa może uczciwie rozumieć przez suwerenność

Europejska suwerenność w infrastrukturze cyfrowej powinna być opisywana w kategoriach, które przetrwają niewygodne pytanie. Może oznaczać, że europejska instytucja zachowuje władzę nad kluczowymi decyzjami. Może oznaczać, że kluczowe zależności są widoczne, ograniczone i możliwe do odzyskania. Może oznaczać, że prawa prawne są dopasowane do możliwości technicznych. Może oznaczać, że publiczny nabywca może zmienić dostawcę, zakwestionować decyzję, przeprowadzić kontrolę i kontynuować działanie, gdy dostawca lub prawo zmieni dostępną ścieżkę.

Nie powinno to oznaczać, że usługa jest automatycznie bezpieczna, ponieważ jej adres marketingowy jest europejski. Nie powinno też oznaczać, że każde zagraniczne połączenie jest zabronione. Europa zależy od systemów transgranicznych, a zasada, która udaje, że jest inaczej, będzie ignorowana lub po cichu obchodzona. Dojrzałe stanowisko jest bardziej wymagające: dopuść zależności, które służą misji, udokumentuj je, ogranicz te, które niosą niedopuszczalną władzę, i zachowaj wyjście dla tych, których nie można uczynić godnymi zaufania.

To stanowisko daje też europejskim dostawcom uczciwszy test. Lokalny dostawca nie powinien musieć odprawiać ceremonii flagowej, aby być traktowanym poważnie. Powinien móc pokazać, co obsługuje, co deleguje, kto ma do tego dostęp, jakie prawo może mieć zastosowanie, jak chronione są dane i jak klient może odejść. Globalny dostawca powinien stanąć przed tymi samymi pytaniami. Standardem są dowody kontroli, a nie teatr pochodzenia.

Słowo suwerenność staje się użyteczne, gdy zmienia zachowania zakupowe. Ministerstwo może wykorzystać zamówienia publiczne, aby nagrodzić przetestowaną ścieżkę wyjścia. Szpital może wymagać kluczowych ustaleń zgodnych z jego obowiązkami klinicznymi. Uniwersytet może uczynić pochodzenie danych badawczych widocznym. Regulator może poprosić o stan systemu w momencie podejmowania decyzji. Dostawca może zaprojektować swoją usługę tak, aby władza klienta nie była ozdobnym akapitem. To są działania instytucjonalne, a nie konkurs haseł.

Krótka uwaga od nas

W Dweve nasza publiczna analiza The Sovereignty Illusion: where control really sits, opublikowana 29 czerwca 2026 r., stosuje podobną dyscyplinę. Rozdziela własność, technologię, kapitał, infrastrukturę i ekspozycję prawną, zamiast pozwalać, aby europejska etykieta reprezentowała wszystkie pięć. Ten artykuł jest węższy. Podąża za twierdzeniem o centrum danych w głąb warstw operacyjnych i prawnych, którymi nabywca musi zarządzać.

Tak też wolimy opisywać naszą własną pracę. System powinien czynić swoje granice czytelnymi: co jest lokalne, co delegowane, co rejestrowane, co można zakwestionować i co można zmienić. Użyteczne twierdzenie to takie, które czytelnik może zweryfikować. Reszta to dekoracja, a Europa ma już mnóstwo dekoracyjnej infrastruktury.

Argument prawny zaczyna się po adresie

Lokalizacja centrum danych jest warta poznania. Może wpływać na fizyczny dostęp, odporność, łączność, obowiązujące przepisy lokalne i projekt usługi. Może być właściwym pierwszym pytaniem. Jest jednak słabą odpowiedzią ostateczną.

The final answer has to connect place to authority. It has to name the operator, the identities, the keys, the subcontractors, the legal tools, the possible requests, the evidence and the exit. For personal data, the European level of protection must remain essentially equivalent when the data is transferred, and exporters have to assess the circumstances rather than repeat a location claim. For non-personal data, the Data Act adds rules about foreign access and cloud switching, which again make control and portability concrete.

There is no single European number that can turn a complicated service into a sovereign one. There is a sequence of questions, tests and records. The sequence is slower than printing “EU hosted” on a brochure. It is also the part that remains useful after the brochure has gone out of date.

When a buyer asks where the data is, answer the location precisely. Then ask who can read it, who can act on it, who can be compelled, who can prove what happened and who can leave. A European data centre can be part of a trustworthy arrangement. It cannot be the legal argument on its own.

Sources

• Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, European Data Protection Board, final version 18 June 2021. The linked page includes the official PDF.
• Case C-311/18, Data Protection Commissioner v Facebook Ireland and Schrems II, Court of Justice of the European Union, judgment 16 July 2020, EUR-Lex.
• Regulation (EU) 2023/2854, the Data Act, European Parliament and Council, 13 December 2023, EUR-Lex.
• Data Act explained, European Commission, published 2025 and accessed 5 August 2026.
• Cloud Computing Risk Assessment and the official report PDF, European Union Agency for Cybersecurity (ENISA), 2009.
• The Sovereignty Illusion: where control really sits, Dweve, 29 June 2026.