En överföringsbedömning till tredjeland, en TIA, krävs varje gång EDPB:s tre kriterier för överföring är uppfyllda och mottagaren finns utanför EU/EES. Prioritera i denna ordning: kontrollera om ett adekvansbeslut gäller, säkerställ lämpliga skyddsåtgärder som SCC eller BCR, och pröva artikel 49 endast som sista utväg. Om ingen kombination av rättslig grund och tekniska åtgärder räcker för att sänka risken till en godtagbar nivå, ska ni avstå från överföringen och dokumentera varför.
Kort sagt:
- Endast när ett adekvansbeslut gäller eller tekniska skyddsåtgärder som SCC eller BCR är på plats kan en dataöverföring till tredjeland vara godtagbar.
- Fjärråtkomst för support, backup-replikering i tredjeland och systemunderhåll utanför EU/EES räknas som överföringar så snart någon kan se eller bearbeta personuppgifterna.
- Om lagstiftning i mottagarlandet kan undergräva skyddet trots avtal och tekniska åtgärder, kan en fullständig TIA visa att överföringen måste stoppas eller kompletteras.
- SCC måste kopplas till en detaljerad TIA som kartlägger faktiska dataflöden och juridiska risker, samt innehåller verifierbara tekniska och organisatoriska skydd.
- Vid osäkerhet bör man avstå från överföringen och dokumentera beslutet, speciellt om det inte finns adekvansbeslut eller tillräckliga tekniska skalskydd.
Innehållsförteckning
- Vad räknas som en överföring till tredjeland?
- Vilka rättsliga grunder gäller för överföring till tredjeland?
- Hur väljer ni SCC-modul och kopplar den till en TIA?
- Vilka tekniska och organisatoriska åtgärder sänker risken faktiskt?
- När ska ni avstå från en tredjelandsöverföring?
- Vilken dokumentation förväntar sig tillsynsmyndigheten?
- Så genomför ni en fullständig TIA steg för steg
- Vad erfarenheten från praktiska TIAs faktiskt visar
- Hur Trustview stödjer arbetet med överföringsbedömningar
- Källor
- Vanliga frågor
Vad räknas som en överföring till tredjeland?
Ett vanligt misstag är att tro att all datatrafik utanför Sverige automatiskt är en tredjelandsöverföring. Det stämmer inte. EDPB:s riktlinjer 05/2021 slår fast tre kumulativa kriterier som måste vara uppfyllda samtidigt för att kapitel V i GDPR ska aktiveras.
Det första kriteriet är att en personuppgiftsansvarig eller ett personuppgiftsbiträde omfattas av GDPR för den aktuella behandlingen. Det andra är att denna aktör lämnar ut uppgifterna, genom överföring eller på annat sätt tillgängliggör dem, till en annan aktör (mottagaren). Det tredje kriteriet är att mottagaren befinner sig i ett tredjeland eller är en internationell organisation, oavsett om mottagaren själv omfattas av GDPR för sin egen behandling.
Ett konkret exempel: om ert svenska bolag skickar en kunddatabas till ett systerbolag i Singapore för lokal marknadsföring, är alla tre kriterierna uppfyllda. Men om en anställd i Sverige loggar in på ett system som fysiskt ligger i ett EU-datacenter, samtidigt som en leverantör i USA har fjärråtkomst för support, uppstår en överföring i det ögonblick den amerikanska supportpersonalen faktiskt kan se eller bearbeta uppgifterna, inte bara i det ögonblick data lagras i EU.
Gränsdragningarna blir ofta svårast i tre situationer:
- Supportåtkomst från tredjeland: även en tillfällig fjärrinloggning för felsökning räknas som en överföring om supportpersonalen kan se personuppgifter, oavsett hur kort sessionen är.
- Spegling och backuper: om en säkerhetskopia replikeras till en server i ett tredjeland, uppstår en överföring vid replikeringstillfället, inte bara vid en eventuell återställning.
- Fjärrdrift och underhåll av system: om ett tredjelandsbolag administrerar en databas som fysiskt står i EU men har full åtkomst till innehållet, bedöms det som en överföring enligt EDPB:s tolkning av tillgänglighet snarare än fysisk lagringsort.
För en snabb preliminär bedömning i praktiken, ställ två frågor direkt: Var befinner sig varje aktör som kan läsa, ändra eller radera uppgifterna, inklusive underleverantörer till underleverantörer? Och: finns det något tillfälle, även kortvarigt, då en aktör utanför EU/EES får teknisk åtkomst till klartext eller dekrypterbara uppgifter? Om svaret på den andra frågan är ja, ska ni gå vidare med en fullständig TIA.
Vilka rättsliga grunder gäller för överföring till tredjeland?
GDPR ger exportören tre vägar att välja mellan, och de är inte likvärdiga i praktiken. IMY:s vägledning om överföring till tredjeland beskriver dem som en tydlig hierarki snarare än tre parallella alternativ.
Adekvansbeslut enligt artikel 45
Ett adekvansbeslut innebär att EU-kommissionen har bedömt att ett land, en sektor eller ett specifikt regelverk i landet ger en skyddsnivå som i huvudsak motsvarar EU:s. EU-kommissionens sida om adekvansbeslut listar vilka länder som omfattas för närvarande, och listan förändras över tid eftersom besluten kan omprövas eller upphävas.
Praktisk konsekvens: när ett adekvansbeslut gäller behöver ni inte SCC eller andra skyddsåtgärder för den specifika överföringen. Det betyder dock inte att ni kan hoppa över dokumentationen helt. Ni måste fortfarande kunna visa att mottagarlandet och den specifika mottagaren faktiskt omfattas av beslutet, eftersom vissa adekvansbeslut är begränsade till särskilda sektorer eller certifieringsprogram. Ett bolag i ett adekvansland som inte är certifierat enligt det aktuella programmet omfattas inte automatiskt.
Lämpliga skyddsåtgärder enligt artikel 46
När inget adekvansbeslut finns, vilket gäller de flesta tredjeländer inklusive USA för bolag utanför särskilda certifieringsramverk, måste ni använda ett av instrumenten i artikel 46. De vanligaste i praktiken är:
- Standardavtalsklausuler (SCC): EU-kommissionens fasta avtalstext som binder exportör och importör till specifika skyldigheter.
- Bindande företagsbestämmelser (BCR): används inom koncerner och kräver godkännande från en tillsynsmyndighet, vilket gör processen tyngre men mer flexibel över tid.
- Godkända uppförandekoder och certifieringar: mindre vanliga i praktiken men relevanta inom vissa branscher med etablerade branschstandarder.
SCC är standardvalet för de flesta bolag eftersom klausulerna är färdigskrivna och inte kräver myndighetsgodkännande i förväg. Det som skiljer en fungerande SCC-implementering från en som bara ligger i en pärm är om bilagorna faktiskt speglar verkligheten, vilket vi går igenom i nästa avsnitt.
Undantag enligt artikel 49
Artikel 49 tillåter överföring i specifika situationer, exempelvis vid uttryckligt samtycke, för att fullgöra ett avtal, eller vid viktigt allmänt intresse. Både IMY och EDPB betonar att dessa undantag är avsedda för tillfälliga, icke-repetitiva situationer, inte som en permanent grund för löpande dataflöden.
Ett bolag som bygger sin ordinarie drift på artikel 49-samtycke, till exempel genom att låta varje kund klicka i en samtyckesruta för att möjliggöra löpande molnlagring i USA, bygger på en grund som tillsynsmyndigheter aktivt ifrågasätter. Samtycke måste vara specifikt, informerat och frivilligt för varje enskild överföring, vilket i praktiken är svårt att upprätthålla för kontinuerliga systemintegrationer. Se artikel 49 som en nödlösning för engångssituationer, inte som en genväg runt SCC-arbetet.
Hur väljer ni SCC-modul och kopplar den till en TIA?
SCC-dokumenten från EU-kommissionen är inte en enda mall utan fyra moduler beroende på vilka roller de inblandade parterna har. Att välja fel modul är ett av de vanligaste felen vi ser i granskade avtal.
De fyra modulerna i korthet
| Modul | Exportör | Importör | Typisk situation |
|---|---|---|---|
| Modul 1 | Personuppgiftsansvarig | Personuppgiftsansvarig | Två fristående bolag delar data för egna ändamål |
| Modul 2 | Personuppgiftsansvarig | Personuppgiftsbiträde | Ni lejer ut behandling till ett tredjelandsbiträde |
| Modul 3 | Personuppgiftsbiträde | Underbiträde | Ert biträde anlitar ett underbiträde i tredjeland |
| Modul 4 | Personuppgiftsbiträde | Personuppgiftsansvarig | Ovanlig situation där biträdet överför till den ansvariges tredjelandskontor |
EU-kommissionens sida om standardavtalsklausuler innehåller den fullständiga texten och vägledning kring vilka klausuler som är valbara inom varje modul, till exempel bestämmelser om vidareöverföring till ytterligare underbiträden.
Modul 2 är den vanligaste i praktiken för svenska bolag, eftersom situationen ofta handlar om att ett molntjänstbiträde med säte i USA behandlar personuppgifter för ert bolags räkning. Men se upp med kedjor: om ert amerikanska biträde i sin tur anlitar ett underbiträde i Indien, behöver den relationen sin egen SCC enligt modul 3, och den kopplingen missas ofta i praktiken.
Vad bilagorna faktiskt måste innehålla
SCC-huvudtexten är fast, men bilagorna är där det praktiska arbetet ligger, och det är också där tillsynsmyndigheter oftast hittar brister vid granskning. En fungerande bilaga beskriver:
- Ändamålet med behandlingen, formulerat konkret nog att det går att kontrollera mot vad systemet faktiskt gör, inte en generisk beskrivning som “molntjänster”.
- Kategorier av personuppgifter och registrerade, inklusive om känsliga kategorier enligt artikel 9 ingår, vilket höjer kravet på skyddsåtgärder.
- Lagringstid, kopplad till er faktiska gallringsrutin snarare än en schablonformulering.
- Tekniska och organisatoriska skyddsåtgärder, beskrivna så specifikt att de går att verifiera, till exempel vilken krypteringsstandard som används och vem som innehar nycklarna.
- Underbiträden med namn och plats, uppdaterade löpande i takt med att leverantörskedjan förändras.
En bilaga som skriver “lämpliga tekniska åtgärder tillämpas” utan att specificera vilka är i praktiken meningslös vid en tillsynsgranskning. Tillsynsmyndigheten kan och kommer att fråga efter den konkreta konfigurationen.
Kopplingen mellan SCC och TIA
SCC är avtalet. TIA är bevisningen för att avtalet faktiskt fungerar i mottagarlandets rättsliga verklighet. En TIA ska besvara en enkel men ofta obekväm fråga: kan mottagarlandets lagstiftning, till exempel regler om myndighetsåtkomst till data, i praktiken underminera de skyddsåtgärder SCC utlovar?
En fullgod TIA innehåller alltid tre delar i följd. Först en kartläggning av det faktiska dataflödet, systemarkitekturen och alla inblandade aktörer, inklusive underleverantörer. Sedan en scenarioanalys av mottagarlandets lagstiftning och praxis, med särskilt fokus på om myndigheter kan begära åtkomst utan rättslig prövning som motsvarar EU:s standard. Till sist en slutsats som antingen bekräftar att SCC plus befintliga åtgärder räcker, eller identifierar konkreta kompletteringar som krävs innan överföringen kan ske. EDPB:s rekommendationer 01/2020 beskriver just den processen för hur kompletterande åtgärder ska bedömas mot mottagarlandets rättsliga miljö. En strukturerad genomgång av TIA-processen hjälper er hålla ordning på de tre stegen utan att tappa spårbarhet mellan kartläggning och slutsats.
Vilka tekniska och organisatoriska åtgärder sänker risken faktiskt?
EDPB:s rekommendationer 01/2020 är tydliga på en punkt som många missar: en komplettering måste faktiskt neutralisera den risk mottagarlandets lagstiftning skapar, inte bara se bra ut i ett avtal. En policy om “starkt lösenordsskydd” gör ingenting för att skydda mot en myndighet som kräver ut data direkt från leverantören.
De tekniska åtgärder som i praktiken gör skillnad är:
- Kryptering med kundkontrollerade nycklar (BYOK): om leverantören i tredjeland inte har tillgång till dekrypteringsnyckeln, kan de heller inte lämna ut läsbar data även om de tvingas till det.
- Klientsidekryptering: data krypteras innan den lämnar EU/EES och dekrypteras först på er sida, vilket gör mottagaren i tredjeland till en ren lagringsplats för chiffertext.
- Pseudonymisering med nyckel kvar i EU: separerar identifierande uppgifter från övrig data så att en eventuell utlämning inte avslöjar en identifierbar person.
- Segmenterad åtkomst: endast de specifika datamängder som behövs för det avtalade ändamålet exponeras för mottagaren, aldrig hela databasen.
Organisatoriska åtgärder väger tyngre än många tror, särskilt i kombination med teknik. Tidsbegränsad och loggad supportåtkomst, där varje session till produktionsdata registreras med tidsstämpel och person, ger er ett spårbart bevis om något går fel. Platsbindning av personal, det vill säga avtalskrav på att endast namngivna medarbetare i specifika länder får hantera supportärenden, minskar exponeringen jämfört med en global supportpool utan geografisk avgränsning. Praktiska exempel på verktyg som stödjer sådan loggning finns i genomgången av dataskyddsverktyg för GDPR-efterlevnad.
Proffstips: Testa alltid en komplettering mot en konkret fråga: “Om myndigheten i mottagarlandet ställer krav på utlämning i morgon, förändrar den här åtgärden vad de faktiskt kan få ut?” Om svaret är nej, är åtgärden kosmetisk, inte skyddande.
Kompletteringar gör verklig skillnad när de bryter kedjan mellan begäran och läsbar data, som vid klientsidekryptering utan nyckeltillgång för mottagaren. De räcker sällan när lagstiftningen i mottagarlandet ger myndigheter rätt att kräva teknisk assistans från leverantören själv, vilket kan tvinga fram nyckelutlämning oavsett avtalstext. I sådana fall är den ärliga slutsatsen i TIA:n att risken kvarstår oavsett hur många tekniska lager ni lägger på.
När ska ni avstå från en tredjelandsöverföring?
Ibland är den korrekta juridiska slutsatsen att inte genomföra överföringen alls, och det är en giltig och ofta nödvändig utgång av en TIA, inte ett misslyckande i processen.
Sätt acceptanskriterier för residualrisk innan ni börjar analysen, inte efter. Fråga: vilken typ av data hanteras (känsliga kategorier enligt artikel 9 kräver en betydligt lägre risktolerans än allmänna kontaktuppgifter)? Vilken åtkomst har mottagaren i praktiken, begränsad eller obegränsad? Och hur sannolikt är myndighetsåtkomst i mottagarlandet utifrån dokumenterad praxis, inte enbart lagtext?
En beslutsmatris med tre nivåer fungerar väl i praktiken: godkänn direkt när residualrisken är låg och väldokumenterad, godkänn med villkor när kompletterande åtgärder sänker risken till en acceptabel nivå men kräver uppföljning, eller avslå när ingen kombination av rättslig grund och teknisk åtgärd räcker. Varje nivå ska kräva sin egen dokumentation och sin egen godkännandenivå, till exempel att nivå tre alltid eskaleras till dataskyddsombudet eller juridisk rådgivare innan beslut fattas.
En åtgärdsplan efter en villkorad TIA-slutsats ska namnge varje krävd komplettering, ansvarig person, deadline och en tydlig verifieringsmetod, till exempel ett loggutdrag som visar att kryptering faktiskt implementerats. Schemalägg omprövning minst årligen, och tidigare om mottagarlandets lagstiftning förändras eller om en ny underleverantör tillkommer i kedjan.
Vilken dokumentation förväntar sig tillsynsmyndigheten?
Vid en tillsyn eller tvist är det inte den juridiska slutsatsen i sig som avgör utfallet, utan om ni kan bevisa att ni faktiskt genomförde bedömningen ni påstår. Ett paket som håller vid granskning innehåller normalt:
- Fullständigt SCC-paket, inklusive alla bilagor med aktuella uppgifter om ändamål, datakategorier och skyddsåtgärder.
- Underbiträdeslistor som visar samtliga aktörer i kedjan, uppdaterade i takt med förändringar hos leverantören.
- Den kompletta TIA-dokumentationen, med kartläggning, scenarioanalys och slutsats i ett sammanhängande dokument, inte lösa anteckningar.
- Tekniska bevis, till exempel konfigurationsutdrag som visar krypteringsnivå och vem som innehar nycklarna (KMS-inställningar).
- Loggutdrag som styrker att organisatoriska åtgärder som tidsbegränsad supportåtkomst faktiskt tillämpas i drift, inte bara på papper.
- Processdokumentation som visar när TIA:n senast omprövades och vem som godkände den.
Tekniska bevis väger tyngre än en beskrivande text. En rad som säger “data krypteras” är svag. Ett utdrag som visar krypteringsalgoritm, nyckellängd och var nyckeln lagras är starkt, eftersom det går att verifiera oberoende av vem som skrivit dokumentet.
Versionera varje TIA och SCC-bilaga med datum och ansvarig person, så att ni kan visa en historik snarare än ett enda statiskt dokument. IT-Juridik pekar på att just bristen på löpande uppdatering, snarare än den ursprungliga bedömningen, är det som oftast gör att en tidigare godkänd överföring blir problematisk vid en senare granskning. Lägg in årlig omprövning i er kalender som en fast rutin, inte som en engångsinsats vid avtalstecknandet.
Så genomför ni en fullständig TIA steg för steg
En TIA som håller vid granskning följer samma logiska ordning varje gång, oavsett hur komplext dataflödet är.
- Kartlägg dataflödet i detalj. Identifiera varje aktör som kan komma åt personuppgifterna, inklusive underbiträden och deras underbiträden, samt exakt vilken data som är i rörelse.
- Fastställ rättslig grund. Kontrollera om ett adekvansbeslut gäller för mottagarlandet, och om inte, säkerställ att korrekt SCC-modul finns på plats.
- Analysera mottagarlandets rättsliga miljö. Bedöm om lagstiftning om myndighetsåtkomst, övervakning eller nationell säkerhet kan tvinga fram utlämning av data i strid med SCC-åtagandena.
- Gör en scenarioanalys. Beskriv konkret vad som händer om en begäran om utlämning inkommer, och vilka tekniska eller organisatoriska hinder som finns för att den ska lyckas.
- Bedöm om kompletterande åtgärder krävs. Utgå från EDPB:s rekommendationer 01/2020 och testa varje åtgärd mot frågan om den faktiskt bryter kedjan till läsbar data.
- Dra en tydlig slutsats. Formulera slutsatsen som ett av tre utfall: godkänd utan villkor, godkänd med namngivna villkor, eller avslag med motivering.
- Dokumentera och planera uppföljning. Spara hela underlaget versionerat och sätt datum för nästa omprövning.
En bra mallformulering för en villkorad slutsats lyder ungefär: “Överföringen godkänns under förutsättning att klientsidekryptering med nyckelkontroll hos exportören implementeras senast [datum], samt att supportåtkomst begränsas till loggad och tidsbegränsad session. Omprövning sker senast tolv månader efter godkännande eller vid väsentlig förändring av underbiträdeskedjan.” En sådan formulering ger både juridisk tydlighet och en konkret checklista för uppföljning. För att strukturera hela flödet och undvika att viktiga steg glöms bort i en stressad process kan en genomgång av tredjelandsöverföringar och säker efterlevnad vara ett bra komplement till den interna checklistan.
Proffstips: Har ni begränsad tid, lägg den först på kartläggningen av underbiträdeskedjan. De flesta TIA-fel vi ser handlar inte om fel juridisk slutsats, utan om att ett underbiträde i tredjeland aldrig identifierades från början.
Vad erfarenheten från praktiska TIAs faktiskt visar
Den vanligaste missuppfattningen om TIA-arbete är att det är en engångsuppgift som avslutas när dokumentet undertecknas. I praktiken är en TIA en levande process. Leverantörskedjor förändras, molntjänster byter underbiträden utan att alltid meddela det tydligt, och lagstiftning i tredjeländer förändras snabbare än de flesta avtal hinner uppdateras.
Det som faktiskt avgör om en TIA håller vid granskning är inte hur elegant den juridiska analysen är skriven, utan om den backas av verifierbara tekniska bevis och en avtalsstruktur som speglar verkligheten. Ett SCC-paket utan tekniska bevis är ett löfte. Ett SCC-paket med loggutdrag och krypteringskonfiguration är bevisning.
Samverkan mellan juridik, IT och leverantörsansvariga är den svagaste länken i de flesta organisationer. Juristen skriver avtalsbilagorna, men det är IT-avdelningen som vet om krypteringen faktiskt implementerats som beskrivet. Boka in en gemensam avstämning inför varje TIA, inte bara en juridisk genomgång i efterhand.
— Jesper
Hur Trustview stödjer arbetet med överföringsbedömningar
Plattformar för compliance samlar registerförteckning, TIA-mallar och uppföljning på ett ställe, vilket är det som faktiskt skiljer en TIA som hålls levande från en som glöms bort i en mapp efter signering.
Istället för att bygga varje TIA från ett tomt Word-dokument kan strukturerade arbetsflöden koppla kartläggning, scenarioanalys och slutsats direkt till registerförteckningen över behandlingar, så att en förändring hos ett underbiträde automatiskt flaggar vilka TIAs som behöver omprövas.
För organisationer som behöver mer än verktyget själva finns möjlighet att komplettera med juridisk rådgivning för de svårare gränsfallen, till exempel när en ny leverantörskedja ska bedömas för första gången. Priser för plattformen Trustview börjar från 2 500 kr per månad, och ni hittar aktuell information om paket och tillägg direkt på prissidan.
Källor
Varje TIA bör förankras i primärkällor, inte i sekundära tolkningar av dem, eftersom det är dessa dokument en tillsynsmyndighet själv utgår från vid granskning.
- Riktlinjer 05/2021 om samspelet mellan tillämpningen av artikel 3 och bestämmelserna om internationella överföringar enligt kapitel V i dataskyddsförordningen
- Överföring av personuppgifter till tredjeland | IMY
- Överföringar till tredjeland – SCCs & bedömningar – IT-Juridik
Dessa fyra källor täcker tillsammans hela kedjan från definition till avtalsimplementering, vilket gör dem till den naturliga referensramen för varje TIA-dokumentation ni lämnar in vid en eventuell granskning.
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
Vad är skillnaden mellan en DPIA och en TIA?
En DPIA bedömer risker för registrerade vid en specifik behandling generellt, medan en TIA specifikt bedömer om en överföring till tredjeland är säker givet mottagarlandets rättsliga miljö. De kan behövas parallellt för samma projekt, och skillnaderna beskrivs närmare i guiden om konsekvensbedömning.
Krävs en TIA för alla överföringar till tredjeland?
En TIA krävs när överföringen sker med stöd av lämpliga skyddsåtgärder enligt artikel 46, till exempel SCC, eftersom ni måste visa att mottagarlandets lagstiftning inte underminerar skyddet. Vid ett giltigt adekvansbeslut krävs normalt ingen fullständig TIA för den specifika överföringen.
Hur ofta ska en TIA omprövas?
Omprövning bör ske minst årligen, samt omedelbart vid förändringar i underbiträdeskedjan eller om mottagarlandets lagstiftning förändras väsentligt. Att behandla SCC och TIA som statiska dokument är en av de vanligaste orsakerna till att en tidigare godkänd överföring senare ifrågasätts.
Kan artikel 49 användas som permanent lösning?
Nej, artikel 49-undantag är avsedda för tillfälliga, icke-repetitiva situationer, inte som grund för löpande dataflöden. Tillsynsmyndigheter ser rutinmässig användning av artikel 49 som en varningssignal snarare än en giltig långsiktig lösning.
Vad kostar det att använda Trustview för TIA-arbete?
Plattformen Trustview kostar från 2 500 kr per månad, med möjlighet att lägga till juridisk rådgivning för mer komplexa bedömningar. Aktuella priser och paket finns på Trustviews prissida.
