Säkert datacenter med serverrack

CLOUD Act och GDPR: den juridiska konflikt du inte kan avtala bort

Nej. En amerikansk begäran under CLOUD Act gör inte automatiskt en dataöverföring förenlig med GDPR. CLOUD Act ger amerikanska myndigheter rätt att kräva ut data från amerikanska leverantörer oavsett var i världen den lagras, men GDPR artikel 48 kräver en internationell rättslig grund, ett avtal eller en giltig undantagsgrund, innan uppgifterna får lämnas ut. Konflikten löses inte generellt. Den måste bedömas fall för fall, och det är datakontrollanten, inte leverantören, som bär risken.


Kort sagt:

  • En begäran om data enligt CLOUD Act är inte automatiskt förenlig med GDPR och kräver separat juridisk prövning för varje specifikt fall.
  • Under Schrems II krävs tekniska skyddsåtgärder som kryptering och kontroll av nycklar för att göra dataöverföringar till USA tillräckligt säkra.
  • Giltiga internationella överenskommelser, som rättshjälpsavtal, är en förutsättning för att erkänna och verkställa utländska domstolsbeslut enligt GDPR.
  • Organisationer måste alltid bedöma laglig grund enligt GDPR:s steg ett och överföringsgrund enligt kapitel V, inte bara förlita sig på avtal eller marknadsföring.
  • Proaktiv riskbedömning, tekniska lösningar och noggrann kontraktsgranskning är nyckeln för att minimera riskerna vid datautlämning till amerikanska myndigheter.

Evertrust
Bedöm riskerna med CLOUD Act
Evertrust hjälper organisationer med GDPR, dataskydd, informationssäkerhet och praktisk hantering av komplexa regelverksfrågor.

Läs mer om Evertrust

Innehållsförteckning

Vad är CLOUD Act och varför träffar den europeisk data i molnet

CLOUD Act antogs i USA 2018 som en ändring av Stored Communications Act, och löste ett specifikt problem för amerikanska åklagare: hur man tvingar fram data som lagras utanför USA. Lagen slår fast att amerikanska tjänsteleverantörer måste lämna ut data de har “possession, custody or control” över, oavsett var servern fysiskt står. Det är denna extraterritoriella räckvidd som gör lagen relevant för molntjänster och GDPR i hela Europa, inte bara för amerikanska bolag.

“Possession, custody or control” är ett vidare begrepp än fysisk lagring. Det handlar om vem som faktiskt kan komma åt och bearbeta data, inte om var hårddisken befinner sig. Ett amerikanskt moderbolag med ett europeiskt dotterbolag som hanterar infrastrukturen kan fortfarande räknas som att ha kontroll, om moderbolaget har teknisk eller administrativ åtkomst till uppgifterna.

Leverantörer är inte helt rättslösa. CLOUD Act innehåller en mekanism där ett bolag kan begära att domstolen upphäver eller ändrar en order om den bedöms strida mot lagen i det land där data lagras, den så kallade comity-analysen. Domstolen vägar då amerikanska intressen mot risken för lagkonflikt, men bedömningen är diskretionär och utfallet osäkert. Amerikanska myndigheters egna resurser om CLOUD Act beskriver processen i detalj, men ger inga garantier för att en europeisk organisation vinner en sådan prövning.

Hur GDPR artikel 48 och kapitel V styr överföringar vid utländska begäranden

Artikel 48 säger rakt ut att ett domstolsbeslut eller en myndighetsbegäran från ett tredjeland bara får erkännas eller verkställas i EU om det finns en internationell överenskommelse, exempelvis ett rättshjälpsavtal, mellan det landet och EU eller en medlemsstat. En amerikansk domstolsorder enligt CLOUD Act uppfyller i sig inte detta krav, oavsett hur bindande den är i USA.

Det betyder inte att all utlämning är förbjuden. Det betyder att den måste gå via en annan rättslig grund i GDPR, och här krävs en tvåstegsbedömning som många organisationer missar

Steg ett handlar om artikel 6: finns det en laglig grund för själva behandlingen, till exempel ett rättsligt åtagande eller ett berättigat intresse? Steg två handlar om kapitel V: finns det en giltig grund för just överföringen till tredjeland, standardavtalsklausuler, bindande företagsbestämmelser eller ett beslut om adekvat skyddsnivå? Båda stegen måste klara sig oberoende av varandra. Ett företag kan ha en fullt laglig grund för behandlingen enligt artikel 6 och samtidigt sakna en giltig överföringsgrund enligt kapitel V, vilket gör hela utlämningen otillåten.

Många leverantörer och till och med jurister försöker luta sig mot artikel 49:s undantag, till exempel “viktiga allmänna intressen” eller nödvändighet för att fastställa rättsliga anspråk, för att motivera en snabb utlämning. Det håller sällan. Tillsynsmyndigheterna är tydliga med att undantagen i artikel 49 ska tolkas restriktivt och aldrig fungera som en standardväg runt de ordinarie överföringsmekanismerna. En amerikansk brottsutredning är inte per automatik ett sådant “viktigt allmänt intresse” ur EU:s perspektiv, även om den är det ur amerikanskt.

Hur GDPR artikel 48 och kapitel V styr överföringar vid utländska begäranden — overview diagram

Vad EDPB, EDPS och Schrems II betyder för din riskbedömning

EDPB och EDPS gjorde en gemensam juridisk bedömning av CLOUD Act redan innan lagen hunnit få full praktisk effekt i Europa, och slutsatsen var restriktiv: det finns mycket få lagliga vägar för en molnleverantör att direkt efterleva en amerikansk begäran utan att riskera att bryta mot GDPR. Myndigheterna rekommenderade uttryckligen att leverantörer under EU-rätt i första hand ska hänvisa till existerande rättshjälpsavtal snarare än att svara direkt på ordern.

Schrems II-domen från EU-domstolen förändrade sedan spelplanen ytterligare. Domen slog fast att standardavtalsklausuler (SCC) i sig inte räcker för att skydda överföringar till USA, eftersom amerikansk övervakningslagstiftning, inklusive CLOUD Act, kan tvinga fram utlämning oavsett vad kontraktet säger. Sedan domen krävs “supplementary measures”, tekniska och organisatoriska tilläggsåtgärder som kryptering, pseudonymisering och stark nyckelseparation, för att en överföring ska kunna anses tillräckligt skyddad. Ett utredningsunderlag om Schrems II och överföringsmekanismer konstaterar att det i vissa molnscenarier helt enkelt inte finns någon effektiv tilläggsåtgärd som löser problemet, särskilt när leverantören själv har teknisk åtkomst till klartextdata.

Det praktiska resultatet: SCC eller bindande företagsbestämmelser (BCR) är en nödvändig grund, men aldrig en tillräcklig sådan. En organisation som bara har ett signerat SCC-avtal och tror sig vara klar har missat halva bedömningen. IAPP:s analys av Schrems II pekar på att avtal och kontrakt sällan räcker ensamma, och att tekniska åtgärder ofta avgör om skyddet är effektivt i verkligheten. En leverantörs marknadsföring av “europeisk molntjänst” eller “datasuveränitet” är för övrigt ingen juridisk garanti i sig, ansvaret för bedömningen ligger fortfarande hos datakontrollanten.

Executive agreements och MLAT: två vägar, samma flaskhals

CLOUD Act öppnar för så kallade executive agreements, bilaterala avtal mellan USA och andra länder som gör det möjligt för utländska myndigheter att begära data direkt från amerikanska leverantörer, och vice versa, utan att gå via traditionell rättshjälp. Problemet för EU är att inget sådant executive agreement finns på EU-nivå ännu. EDPB och EDPS har varit tydliga med att ett heltäckande avtal med starka grundläggande rättighetsskydd är det som faktiskt behövs, inte enskilda medlemsstatsavtal som riskerar att skapa en lapptäckesreglering inom unionen.

Utan ett sådant avtal återstår Mutual Legal Assistance Treaty, MLAT, den klassiska rättshjälpsvägen. MLAT innebär att en myndighet i ett land begär bistånd via en motsvarande myndighet i det andra landet, med domstolsprövning i mottagarlandet. Det ger starkare rättssäkerhet men är notoriskt långsamt, ofta månader, ibland år, vilket gör det opraktiskt vid brådskande brottsutredningar. Det är just den friktionen som fick amerikanska lagstiftare att skapa CLOUD Act från början.

Resultatet är en strukturell flaskhals: den rättssäkra vägen (MLAT) är för långsam för brådskande fall, och den snabba vägen (direkt CLOUD Act-begäran) saknar oftast giltig grund enligt GDPR kapitel V. Det är detta glapp som tvingar varje organisation att göra sin egen riskbedömning istället för att luta sig mot en färdig juridisk lösning.

Executive agreements och MLAT: två vägar, samma flaskhals — overview diagram

Tekniska och organisatoriska åtgärder som faktiskt minskar risken

CLOUD Act är krypteringsneutral. Lagen tvingar inte fram dekryptering av data leverantören inte kan läsa, den tvingar bara fram utlämning av det leverantören faktiskt har tillgång till. Det gör kryptering till det mest konkreta verktyget en organisation har.

Om kunden, inte leverantören, äger krypteringsnycklarna blir det avsevärt svårare att hävda att leverantören har “control” över klartextdata i CLOUD Act:s mening. Det kräver dock organisatorisk mognad: nyckelhantering (KMS) i egen regi, rutiner för nyckelrotation, en beredskapsplan för vad som händer om nycklar komprometteras, och en tydlig beviskedja som visar tillsynsmyndigheten att leverantören faktiskt saknar åtkomst.

Riskreduktion kräver flera samverkande lager, inte ett enda skyddsmedel:

  • Kryptering med kundstyrda nycklar där leverantören aldrig innehar dekrypteringsnyckeln.
  • Datastyrning och minimering som begränsar vilken data som överhuvudtaget lagras hos amerikanska leverantörer.
  • Segmentering och åtkomstkontroll så att en begäran mot ett system inte automatiskt exponerar allt.
  • Leverantörsdue diligence som granskar bolagsstruktur, moderbolagsrelationer och historik av mottagna myndighetsbegäranden.
  • Kontraktsklausuler som förpliktar leverantören att bestrida ogrundade begäranden och underrätta kunden innan data lämnas ut, om lagen tillåter det.

Proffstips: Begär alltid statistik över leverantörens tidigare mottagna myndighetsbegäranden, ofta kallade “transparency reports”. En leverantör som aldrig fått en enda begäran är antingen extremt liten eller extremt otydlig om sin egen rapportering, båda är varningssignaler.

Så agerar du när en begäran om utlämning landar på bordet

En begäran enligt CLOUD Act kräver snabb men strukturerad hantering. Panikartade beslut, i endera riktningen, leder ofta till fel som blir dyrare än begäran själv.

  1. Fastställ vem begäran faktiskt riktar sig mot. Är mottagaren en amerikansk leverantör, ett amerikanskt dotterbolag, eller en europeisk enhet med amerikansk ägarkoppling? Detta avgör om CLOUD Act överhuvudtaget är tillämplig.
  2. Kartlägg exakt vilken data som omfattas. Begäranden är ofta bredare formulerade än nödvändigt, och en europeisk part har rätt att ifrågasätta omfattningen.
  3. Genomför den fulla tvåstegsbedömningen enligt GDPR: finns laglig grund enligt artikel 6, och finns en giltig överföringsgrund enligt kapitel V? Om svaret på någon av delarna är nej, saknas rättslig grund för utlämning.
  4. Kontakta tillsynsmyndigheten vid osäkerhet. EDPB:s och Cleary Gottliebs analyser pekar samstämmigt på att leverantörer utan giltig grund bör hänvisa till MLAT-processen snarare än att svara direkt.
  5. Dokumentera hela beslutskedjan. Vilka bedömningar gjordes, vilken juridisk rådgivning inhämtades, och vilka tekniska bevarandeåtgärder vidtogs, i väntan på ett slutligt beslut.
  6. Underrätta berörda parter om notifieringsskyldighet föreligger, och bedöm om händelsen i sig utgör en personuppgiftsincident som ska anmälas till tillsynsmyndigheten inom 72 timmar.

Ansvarsrisken vilar tungt på datakontrollanten. En sanktionsavgift efter felaktig överföring till en amerikansk molntjänst visar att svenska tillsynsmyndigheter inte ser mellan fingrarna bara för att trycket kom utifrån.

Evertrusts expertblick: när egen kompetens inte räcker till

Jesper på Evertrust möter regelbundet organisationer som upptäcker CLOUD Act-problematiken först när en leverantör redan mottagit en begäran, långt senare än vad som är optimalt. Evertrust arbetar löpande med dataskyddsfrågor, informationssäkerhet och IT-juridik, och ser samma mönster upprepas: kontrakt som aldrig granskats mot Schrems II-kraven, och nyckelstrategier som aldrig testats mot ett verkligt scenario.

En DPIA som specifikt kvantifierar sannolikheten för en CLOUD Act-begäran mot just din leverantörsarkitektur, snarare än en generisk mall, är ofta den första åtgärden som avslöjar var de verkliga bristerna finns. Kontraktsgranskning av befintliga molnavtal, med fokus på notifieringsklausuler och bestridningsskyldigheter, är den andra. En genomarbetad nyckelstrategi, där kunden faktiskt kontrollerar krypteringsnycklarna i praktiken och inte bara på papper, är den tredje.

Organisationer bör kontakta en extern rådgivare i god tid innan en begäran landar, inte efteråt. En dokumenterad DPO-roll i DPIA-processen ger dessutom ett tydligt ansvarsspår gentemot tillsynsmyndigheten.

Vad du bör bevaka framåt

Förhandlingar om ett bredare EU–USA-ramverk för dataöverföring fortsätter, och ett executive agreement enligt CLOUD Act på EU-nivå skulle förändra spelplanen radikalt om det förhandlas fram med de skyddsgarantier EDPB kräver. Samtidigt utvecklas teknik för konfidentiell databehandling som kan göra supplementary measures faktiskt effektiva i fler molnscenarier än idag. Håll ögonen på tillsynsguidning snarare än leverantörsmarknadsföring när du väljer molnstrategi de kommande åren.

— Jesper

Så kan Evertrust hjälpa dig stänga gapet mellan CLOUD Act och GDPR

Evertrust är rådgivningspartnern för organisationer som behöver en juridiskt hållbar väg genom CLOUD Act-frågan, inte bara ett standardavtal i en pärm. Skillnaden mot att lösa detta internt är att du får en extern DPO-roll, en fokuserad kontraktsgranskning och en DPIA som faktiskt räknar på din specifika leverantörsrisk, istället för att gissa dig fram efter att en begäran redan har kommit.

Evertrust

Vi tar rollen som interimsjurist eller externt dataskyddsombud när den interna kompetensen behöver förstärkas snabbt, och driver GAP-analyser som visar var molnavtal kan sakna tilläggsåtgärder Schrems II kräver. Ni får också stöd i frågor om intressekonflikter kring dataskyddsombudsrollen när molnleverantörens och organisationens intressen inte helt sammanfaller.

Boka en inledande genomgång av era molnavtal och er nyckelstrategi via Evertrusts expertisöversikt, så får ni en konkret bild av var er organisation faktiskt står innan nästa begäran landar.

Källor

För djupare juridisk verifiering, gå direkt till EDPB och EDPS gemensamma bedömning av CLOUD Act, till amerikanska justitiedepartementets egna CLOUD Act-resurser, samt till EU-domstolens Schrems II-material via IAPP:s sammanfattande analys. Läs även Evertrusts genomgång av rättspraxis kring känsliga personuppgifter för ytterligare kontext om hur EU-domstolen resonerar kring dataskydd.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Vanliga frågor

Är en CLOUD Act-order automatiskt olaglig enligt GDPR?

Nej, den är inte automatiskt olaglig, men den saknar oftast egen giltig grund enligt artikel 48. Utlämningen måste separat uppfylla GDPR:s krav på laglig grund och giltig överföringsmekanism.

Räcker standardavtalsklausuler för att skydda molndata mot CLOUD Act?

Nej. Efter Schrems II krävs kompletterande tekniska åtgärder som kryptering och nyckelseparation utöver SCC, annars kan skyddet anses otillräckligt.

Kan ett företag vägra att efterleva en CLOUD Act-begäran?

Ja, leverantörer kan utmana en order genom comity-analys i amerikansk domstol, och EDPB rekommenderar att hänvisa till MLAT-processen när ingen giltig internationell grund finns.

Vad händer om mitt företag felaktigt lämnar ut data till amerikanska myndigheter?

Det kan utlösa sanktionsavgift och notifieringsskyldighet som vid en personuppgiftsincident, precis som i fallet med Tullverkets sanktionsavgift efter en molntjänstöverföring.

Hjälper det att välja en europeisk molnleverantör istället för amerikansk?

Det minskar risken betydligt om leverantören saknar amerikansk moderbolagskoppling, men “europeisk” i sig är ingen garanti om bolaget ägs eller kontrolleras från USA.

Rekommendationer

Rulla till toppen

You are currently viewing a placeholder content from HubSpot. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.

More Information

You are currently viewing a placeholder content from HubSpot. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.

More Information

You are currently viewing a placeholder content from HubSpot. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.

More Information