Vägen framåt för molntjänster inom EU är svår. Delvis efter den så kallade Schrems II-domen så uppstod många frågetecken om vad som verkligen gäller för molntjänster samt molntjänstleverantörer. För att läsa mer om vad som gjort att situationen blivit vad den är i dag, läs vår förra artikel om vägen till Schrems II.
I den här artikeln ställs några vanliga frågor som ofta uppkommer vid diskussioner om GDPR och molntjänster, samt svar utifrån den information som finns tillgänglig i nuläget. Mycket kommer dock med stor sannolikhet att förändras under de närmsta åren angående GDPR med tillhörande frågeställningar.
Omfattas vi av GDPR?
För de flesta inom EU så är svaret antagligen ja. Men för de som inte har full koll på GDPR så finns hjälpmedel som hjälper till att dela upp förordningen. Det blir då mer läsbart och lättare att överblicka. Ett exempel på en sådan sektionsuppdelning för GDPR finns här. För de som då omfattas så följer en stor mängd följdfrågor. Några av dem behandlas nedan.
I korthet så står GDPR för General Data Protection Regulation, eller allmänna dataskyddsförordningen på svenska. Förordningen trädde i kraft 2018 och skapades för att etablera en EU-standard för integritetsskydd och för att stärka skyddet som privatpersoner har på internet. GDPR begränsar bland annat privata organisationers och statliga verksamheters möjlighet att samla personuppgifter, och tydliggör att det finns krav på vilka personuppgifter som får behandlas samt hur.
Behandlar vi personuppgifter?
Än en gång så är svaret antagligen ja.
Enligt artikel 4 i GDPR så definieras en personuppgift som följer:
”varje upplysning som avser en identifierad eller identifierbar fysisk person, varvid en identifierbar fysisk person är en person som direkt eller indirekt kan identifieras särskilt med hänvisning till en identifierare som ett namn, ett identifikationsnummer, en lokaliseringsuppgift eller onlineidentifikatorer eller en eller flera faktorer som är specifika för den fysiska personens fysiska, fysiologiska, genetiska, psykiska, ekonomiska, kulturella eller sociala identitet.”
I samma anda så behöver ordet behandling tydliggöras. Även det ordet definieras i artikel 4 av GDPR:
”en åtgärd eller kombination av åtgärder beträffande personuppgifter eller uppsättningar av personuppgifter, oberoende av om de utförs automatiserat eller ej, såsom insamling, registrering, organisering, strukturering, lagring, bearbetning eller ändring, framtagning, läsning, användning, utlämning genom överföring, spridning eller tillhandahållande på annat sätt, justering eller sammanförande, begränsning, radering eller förstöring.”
Sammantaget är att alla åtgärder som hanterar information som relaterar till identifierbara fysiska personer omfattas av GDPR. Det innebär då att den informationen skyddas av GDPR och att adekvata integritetsskyddsåtgärder därmed måste vidtas. Vilka dessa åtgärder är, i sin tur, är inte alltid tydligt. Och något som även rekommenderas av experter är att fall bör utvärderas på fall-till-fall-basis.
Vad innebär det?
Många faktorer påverkar förstås hur uppgifter ska behandlas, men i artikel 5 av GDPR framgår att behandling av personuppgifter måste ske enligt några principer. I korthet ska personuppgiftsbehandling ske på lagligt, korrekt, proportionerligt, öppet (i förhållande till den registrerade), ändamålsbegränsat, uppgiftsminimerat, uppdaterat, lagringsminimerat, samt säkert och integritetsskyddande sätt. Att så är fallet ska även ska kunna påvisas från den personuppgiftsansvariga vid en organisation.
Vidare beskrivs att information inte får ”förvaras i en form som möjliggör identifiering av den registrerade under en längre tid än vad som är nödvändigt för de ändamål för vilka personuppgifterna behandlas.” Undantag gäller dock om ”personuppgifterna enbart behandlas för arkivändamål av allmänt intresse, vetenskapliga eller historiska forskningsändamål eller statistiska ändamål”, om tekniskt och organisatoriskt skydd för uppgifterna finns – vilket i artikel 89 nämns att inkludera pseudonymisering. Troligtvis är det statistiska syftet vanligast när det gäller förlängd förvaring.
Går det att använda molntjänster i EU med GDPR?
Det beror på. Dels beror på det på om molntjänsten registrerar några personuppgifter – vilket är vanligt förekommande på ett eller annat sätt. Det beror även på vilka regioner som molntjänstleverantören verkar i och/eller vilka regioner som har åtkomst till de registrerade uppgifterna.
Det kortaste svaret är därför att det går, men endast om leverantören inte registrerar personuppgifter som kan nås från tredje land, att uppgifterna är anonymiserade/pseudonymiserade alternativt att informationen är krypterad.
Får vi föra över data till tredje land genom GDPR?
En het fråga för GDPR handlar om dataöverföringar, och då framför allt om överföringar till tredje land som inte omfattas av adekvat lagstiftat integritetsskydd. GDPR kräver att skyddet för personuppgifter måste finns för skickad information, oavsett mottagarland och vidare steg. Det är för att det inte ska gå att kringgå eller underminera lagstiftningen genom att skicka data dit GDPR eller motsvarande inte gäller.
I GDPR så framgår dock faktiskt inte någon definition för exakt vad en överföring är. Men i grova drag så kan det ändå konstateras att det inte enbart handlar om personuppgifter som skickas till ett tredje land – exempelvis via e-post, filuppladdningar, systemregistreringar och mer. Det är här mycket viktigt att vara medveten om att även enbart åtkomstmöjlighet från tredje land ska betraktas som en överföring.
Kort uttryckt så är teoretisk åtkomst från tredje land utan adekvata skyddsåtgärder inte förenligt med GDPR. Trots att inte någon exakt definition för överföringar så framgår det tydligt att olika information behöver hanteras på olika sätt. Exempelvis beroende på om information framgår i klartext, om den är pseudonymiserad eller krypterad så förändras lagkontexten. Därför är det av stor vikt att det finns tydliggjort vilka personuppgifter som registreras samt i vilket format.
Vad är TIA-processen?
För att hjälpa till att skapa klarhet efter Schrems II-domen så släppte den Europeiska dataskyddsstyelsen (EDPB) en samling officiella rekommendationer. Först publicerades en remiss av rekommendationerna i november 2020 och senare publicerades en reviderad version i juni 2021. I rekommendationsdokumentet presenteras bland annat den så kallade TIA-metoden som utformades för att underlätta vid tredjelandsöverföringar. Metoden har fått en del uppmärksamhet för att ha gett ett någorlunda standardiserat utvärderingsverktyg för bolag som analyserar GDPR och sina tredjelandsöverföringar.
TIA står för Transfer Impact Assessment och processen är uppdelad i 6 steg. EDPB rekommenderar bolag att utföra dessa steg inför tredjelandsöverföringar. Syftet är att säkerställa så att uppgiftshanteringen sker enligt EU-standard samt för att upprätthålla GDPR-efterlevnad. TIA-stegen är som följer:
- Steg 1: Identifiera vilka överföringar av personuppgifter som görs och att informationen som registreras möter GDPR-krav.
- Steg 2: Verifiera att det finns grund i GDPR (främst artiklarna 45 och 46) till överföringarna.
- Steg 3: Avgör om någon lagstiftning i mottagarlandet kan motverka GDPR-skyddet och överföringsgrunden (artikel 46). Tre exempelscenarion som kräver kompletterande åtgärder är:
- a) Om EU-kompatibel standard finns i mottagarlandet, men att standarden ignoreras eller motverkas.
- b) Om det finns inkompatibel icke-lagstadgad praxis i mottagarlandet.
- c) Om informationen eller mottagaren omfattas av med GDPR inkompatibel eller annan problematisk lagstiftning.
- Steg 4: Identifiera och implementera kompletterande åtgärder för att möta EU-standarden.
- Steg 5: Initiera formella processer, beroende på vilken GDPR-grund (artikel 46) som finns för överföringen.
- Steg 6: Repetera steg 1–5 med jämna mellanrum.
Läs det officiella dokumentet med rekommendationerna och TIA från EDPB här.
Flera experter har konstaterat att TIA-metoden är tids- och resurskrävande, och att det i vissa fall kan vara väldigt svårt att få konkreta svar. Det har lett till att TIA-processen enligt vissa bör betraktas mer som ett stöd när bolaget genomför överföringar, samt som ett hjälpmedel vid GDPR-dokumentation. Dock gör metoden inte mycket för att lösa någon problematik runt att identifiera eller implementera kompletterande uppgifter. Framför allt inte för bolag som inte har dialog med experter på området eller som är beredda att avsätta en stor mängd resurser.
Vilka kompletterande åtgärder finns för GDPR?
Kompletterande åtgärder är ett diffust uttryck som EDPB använder för att motivera ytterligare åtgärder i de fall som GDPR riskerar att inte efterlevas, främst vid tredjelandsöverföringar.
I steg 4 av TIA-processen från EDPB så är rekommendationen att identifiera och implementera så kallade kompletterande åtgärder (supplementary measures). Begreppet kompletterande åtgärder utvecklades inte vidare i första utgåvan av rekommendationerna från EDPB från november 2020, men i den slutgiltiga versionen så nämns tre exempelområden där kompletterande åtgärder kan införas. De tre områdena är det tekniska, det kontraktuella samt det organisatoriska.
Till tekniska kompletterande åtgärder menar EDPB att exempelvis datakryptering, pseudonymisering eller uppdelning av data. Uppdelning av data sker med syftet att avidentifiera personer genom att bara ha en oidentifierbar del som lagras på eller överförs till ett ställe med andra delar lagrade på andra platser och hos andra leverantörer. Då kan de uppdelade delarna i sig själva inte längre kan klassas som personuppgifter samtidigt som informationen fortfarande kan anses vara intakt.
Som en kontraktuell åtgärd rekommenderar EDPB att exempelvis använda de nya standardavtalsklausulerna, vilka ställer avtalsmässiga krav på vilka tekniker som kan och behöver användas. Med andra ord så menar EDPB att rekommendationen är att skapa eller implementera avtalsklausuler för att på så sätt säkerställa EU-standard genom att göra avtalet beroende av GDPR-efterlevnaden.
Till de organisatoriska åtgärderna hör exempelvis att utvärdera och kontrollera organisationens egna processer, och där se till att dataregistrering/-hantering sker enligt EU-standard och andra internationella standarder. Hypotetiska frågor kan ställas om exempelvis en myndighet skulle kräva att viss information lämnas ut, för att från det perspektivet undersöka vilka uppgifter som finns lagrade, samt hur.
Områdesexperter menar dock att den viktigaste punkten är den tekniska, och att alla åtgärder på ett eller annat sätt involverar tekniska åtgärder, även om de börjar analyseras inom organisationen eller anges i avtalet. Det kokar således ner till vilka tekniska möjligheter och hjälpmedel som finns att tillgå – och det är med på den fronten som den mesta utvecklingen lär synas.
Fungerar det att kryptera personuppgifter som överförs till tredje land?
I teorin ja. Men det finns flera saker att se upp med. Utan att gå in på tekniska detaljer så är några av de viktigaste delarna
1) vem som har åtkomst till krypteringsnycklarna,
2) om det gäller data under transport eller i vila, där det då finns olika typer av risker.
Enligt GDPR är kryptering ett adekvat skydd, fast enbart om krypteringsnycklarna inte finns att tillgå för leverantörer som verkar i tredje land som inte omfattas av någon GDPR-motsvarighet. För de allra flesta molnleverantörer så har leverantören möjlighet att skapa åtkomst till den registrerade informationen som tjänsten involverar.
Kravet på krypteringsnyckelhantering skyddar personuppgifter som omfattas av GDPR, men kan drastiskt höja komplexiteten för it-miljön. Dels så kan en separat krypteringslösning innebära fler leverantörer som då behöver samverka med övriga system och tjänster. Och om en tjänst erbjuder inbyggd kryptering så får inte nycklarna vara åtkomliga för leverantören – om de är det så är det inte längre i enlighet med GDPR. Om exempelvis ett myndighetsbeslut begär ut uppgifter som lagras hos en molntjänstleverantör så behöver leverantören helt enkelt svara att de inte har möjlighet. GDPR menar att informationen behöver vara krypterad och att organisationen inte får ha någon form av administrativ eller annan åtkomst till uppgifterna.
Spelar känsligheten av personuppgifter någon roll för GDPR?
Nej. Vare sig det är mycket känsliga uppgifter eller uppgifter som kan anses vara mindre känsliga så gäller GDPR på samma sätt. Så länge definitionen av personuppgifter kan appliceras på informationen så gäller GDPR. I dataskyddsförordningen så framhålls dock att personuppgifter som involverar barn ska hanteras med extra varsamhet. Det finns dock ingen legalpraxis som antyder olika tillvägagångssätt beroende på olika klassificeringar av personuppgifter. Och enligt tolkningar från Schrems II-domen så spelar det för GDPR ingen roll om det handlar om få eller uttömmande personuppgifter.
I Sverige kan däremot Offentlighets- och sekretesslagen (OSL) komma att påverka hur data får hanteras. Om uppgifter är sekretessbelagda så får de inte lämnas ut.
Är GDPR kompatibel med svenska offentlighetsprincipen?
Ja. Offentlighetsprincipen framgår i Tryckfrihetsförordningen, som är en av Sveriges grundlagar. Där framgår det att alla ska kunna ta del av allmänna handlingar, där en del personuppgifter ingår. Dataskyddslagen (DSL) anger att att GDPR inte får appliceras till den grad att den strider mot Tryckfrihetslagen.
När en uppgift begärs ut i Sverige så behöver en sekretessprövning göras, och om slutsatsen blir att ett utlämnande kommer att bryta mot GDPR så ska uppgiften sekretessklassas. Därigenom kan åtkomsten begränsas och inte lämnas vidare. På så vis kan Sverige balansera offentlighetsprincipen och GDPR, och kombinera intressena från handlingsfrihet och integritet. Här besvarar Upphandlingsmyndigheten samma fråga men i djupare detalj.
Vad gäller för myndigheter?
För myndigheter och statlig verksamhet så är kraven striktare. Myndigheter måste följa rådande lagstiftning och kan därför mest troligt inte riskera olagliga lösningar genom leverantörer som verkar i tredje land som omfattas av problematisk lagstiftning. Inte förrän vidare funktionalitet utvecklats eller tills att lagstiftning ändrats för att möjliggöra kompatibilitet.
En omtalad offentlig utredning från Infrastrukturdepartementet som kallas Säker och kostnadseffektiv it-drift (förkortat SOU 2021:1) publicerades i januari 2021. I utredningen analyserades förutsättningarna för att myndigheter skulle kunna utkontraktera it-drift till privata it-aktörer. Hela utredningen finns att läsa här. Myndigheter och it-aktörer fick möjlighet att kommentera utredningens remiss, där kommentarer vanligen inkluderade den starka tolkningen för när information anses vara röjd, eller avslöjad.
Enligt SOU 2021:1 ska det alltså anses som att uppgifterna som en utkontraktering omfattar med nödvändighet behöver anses som röjda. Utredningen argumenterar, med bas i OSL, att uppgifter ska anses som röjda ”oavsett om omständigheterna när uppgifterna tillgängliggjordes tjänsteleverantören var sådana att man – t.ex. pga. kryptering eller annan teknisk säkerhetsåtgärd – inte måste ha räknat med att tjänsteleverantören eller någon annan utomstående skulle komma att ta del av uppgifterna”. Perspektivet om röjning kvarstår alltså även i de fall som informationen är krypterad, och även om ingen tagit del av informationen.
Bland andra Microsoft, Google och Amazon Web Services betonar att mycket fokus framåt bör ligga på krypteringen av information, eftersom det lär vara ett sätt att upprätthålla integritet enligt EU-standard även för molntjänstleverantörer utanför EU. Alla tre bolagen hävdar i sina betänkanden att de anser att kryptering borde klassas som adekvat skydd för att utkontrakterad information, och att den inte med nödvändighet ska behöva anses som röjd. Det perspektivet delas av många olika aktörer och myndigheter, och finns att läsa bland de officiella svaren till remissen av SOU 2021:1.
Bland annat så anges i många av betänkandena att OSL behöver justeras och/eller mer specifikt att röjandebegreppet bör justeras. En utgångspunkt för vidare information om både utredningen och utkontraktering av it-drift för myndigheter ges i Skatteverkets delbetänkande om SOU 2021:1-remissen. Ta del Skatteverkets remissvar här.
Finns det några enkla tips framåt?
Det finns tyvärr inte så många valmöjligheter så länge flera länders lagstiftningar är i konflikt, till exempel CLOUD Act i USA med GDPR i EU.
På den högsta nivån blir valet mellan att bara använda molntjänstleverantörer som verkar där lagstadgat integritetsskydd som motsvarar EU-standard finns, eller att använda molntjänstleverantörer från tredje land men implementera kompletterande åtgärder, eller riskera att bryta mot GDPR. För att se vilka risker som finns, och vilka konsekvenser som det skulle kunna ha, se den här listan över GDPR-sanktioner.
Men eftersom det kan vara svårt att hitta tjänster som möjliggör en effektiv och säker it-drift så överväger nog många fortsätta utforska olika större molntjänsteleverantörer. Och i de fallen så finns det några avslutande råd kan främja både organisationssäkerhet och legalefterlevnad i kontexten av GDPR.
- Om en molntjänstleverantör omfattas av GDPR-lagstiftning eller motsvarande så bör det kontrakteras klausuler om vilka alternativ som finns om lagkontexten som gäller för leverantören ändras. Till exempel om leverantören skulle köpas upp, och därmed börja omfattas av lagstiftning i tredje land som kan vara i konflikt med GDPR. Ett konkret scenarion som är ganska vanligt förekommande är om en EU-baserad leverantör köps upp av ett bolag i USA och då börjar omfattas av CLOUD Act. I sådana fall behöver leverantörens kunder vara medvetna om förändringen. Och om inte leverantören kan påvisa att de upprätthåller adekvat skydd så bör det kontrakteras möjlighet att avsluta kontraktet för att inte riskera att bryta mot GDPR till följd av leverantörsorganisationens förändring.
- Det andra tipset är att alltid begära evidens av leverantörer som hävdar att lagstiftning följs. Påståendet om att ett bolag aldrig kommer lämna ut personuppgifter eller annan information är vanligt att se, men med tanke på övervakningslagstiftningen i bland annat USA så är det viktigt att få insikt i hur det påståendet upprätthålls. Om en myndighet skulle komma med ett utlämningskrav så behöver informationen vara utom räckhåll för leverantören. Därför är det viktigt att begära evidens för hur policyer upprätthålls – inte bara tro på något eftersom organisationen hävdar det.
