Gå till innehållet
Legiscope
Meny
Dataskydd

Överföringsanalys TIA: dokumentera landrisk och skyddsåtgärder

Beslutsunderlag för en bestämd överföring. Praktisk vägledning med exempel, ansvar och kontroller.

En överföringsanalys, ofta kallad Transfer Impact Assessment eller TIA, ska hjälpa er att avgöra om det valda överföringsstödet fungerar för en bestämd överföring av personuppgifter. Analysen behöver koppla ihop mottagare, uppgifter, tillämplig rätt och faktiska skydd. Den kan leda till att en överföring får genomföras, behöver ändras eller måste stoppas.

Börja därför med det konkreta dataflödet. ”Leverantören finns i USA” eller ”servrarna finns inom EU” räcker inte. Ni behöver veta vilken juridisk person som får tillgång, från vilket land, för vilket arbete och med vilka möjligheter att läsa eller lämna ut uppgifterna. Den här arbetsgången ger er ett granskningsunderlag och två ifyllda beslutsexempel med tydligt angivna antaganden.

1. Kontrollera om detta är rätt analys

Reglerna om överföring till tredjeland finns i kapitel V i GDPR. När ni använder skyddsåtgärder enligt artikel 46, exempelvis standardavtalsklausuler, behöver ni bedöma om skyddet är effektivt i den aktuella situationen. Det är denna fråga TIA-arbetet behandlar. Övriga krav, som rättslig grund för själva behandlingen och uppgiftsminimering, kvarstår.

En överföring som omfattas av ett giltigt beslut om adekvat skyddsnivå enligt artikel 45 följer en annan väg. För USA gäller beslutet mottagare och behandlingar som omfattas av EU–U.S. Data Privacy Framework, inte automatiskt varje amerikanskt företag. IMY förklarar DPF och överföringar till USA. En sådan överföring behöver inte kompletteras med en Schrems II-analys av ytterligare skyddsåtgärder enbart för att mottagaren finns i USA.

Kontrollera den exakta mottagaren och omfattningen innan ni väljer väg. En koncerns marknadsföringsnamn räcker inte som bevis för att rätt dotterbolag är anslutet. Om ni i stället överväger ett undantag i artikel 49 behöver dess särskilda villkor prövas. Det är ingen rutinmässig reservlösning för en löpande tjänst vars skydd annars inte håller.

2. Kartlägg hela överföringen

Skapa en post per sammanhängande överföringssituation. Ange exportör och importör med juridiskt namn, land och roll. Beskriv uppgiftskategorier, registrerade, ändamål, frekvens, lagringstid och format. Ta med fjärrsupport, administration, säkerhetskopior och vidareöverföringar till andra mottagare.

Utgå från systemkartan, men be tjänsteägaren bekräfta hur lösningen faktiskt används. En funktion kan vara avstängd i avtalsunderlaget men aktiverad av ett team. Om en supporttekniker kan se kundinnehåll behöver den åtkomsten beskrivas även om det vanliga lagringsalternativet heter ”EU-region”.

Ifylld startpost i ett fiktivt projekt: Ett svenskt företag köper en ärendetjänst från en leverantör inom EES. Ett separat underbiträde i ett tredjeland ska felsöka vissa ärenden. Den planerade åtkomsten omfattar namn, mejladress, ärendetext och bifogade skärmbilder. Den är händelsestyrd och kan innebära läsning av klartext. Landbedömning och överföringsstöd är ännu inte godkända. Åtkomsten ska därför inte aktiveras i väntan på utredningen.

Den sista meningen är viktig: en kartlagd situation är inte en godkänd situation. Markera okända uppgifter och ansvarig för varje svar. En tom kolumn får inte automatiskt tolkas som att ingen vidareöverföring sker.

3. Identifiera det faktiska överföringsstödet

Om standardavtalsklausuler används behöver ni veta vilka parter och roller de täcker. Ett avtal mellan er och EES-leverantören är inte automatiskt ett överföringsavtal med underbiträdet. Följ kedjan och kontrollera tillämplig modul och bilagor. Vår guide till SCC och bilagorna behandlar själva avtalsarbetet.

EU-kommissionens beslut 2021/914 om standardavtalsklausuler innehåller i klausul 14 en bedömning av lokal rätt och praxis som påverkar efterlevnaden. Dokumentera hur den valda avtalslösningen passar mottagaren och behandlingen. BCR, bindande företagsbestämmelser, är ett annat möjligt stöd inom en koncern, men ersätter inte behovet att bedöma skyddets faktiska funktion.

Skilj detta från en leverantörs allmänna säkerhetscertifiering. Att leverantören har granskats mot en säkerhetsstandard visar inte i sig att en viss tredjelandsöverföring omfattas av ett giltigt stöd. Om val mellan flera mekanismer återstår, använd vår jämförelse av BCR, SCC och DPF innan ni slutför analysen.

4. Bedöm rätt och praxis för just mottagaren

Undersök vilka regler som kan påverka mottagarens möjlighet att uppfylla överföringsstödet. Fokusera på tillämpliga befogenheter till myndighetsåtkomst, begränsningar, tillsyn och möjligheter till rättelse. Bedöm även relevant praxis. Ett allmänt dokument om landets dataskyddslag är otillräckligt om det inte behandlar regler som faktiskt kan gälla den aktuella tjänsten.

IMY:s vägledning om Schrems II och överföringar beskriver varför ytterligare skydd kan behövas när mottagarlandets rätt eller praxis påverkar skyddsnivån. Bedömningen är fortsatt relevant för överföringar som inte omfattas av ett beslut om adekvat skyddsnivå. Undvik därför att kopiera ett äldre landssvar utan kontroll av senare rättsliga förändringar.

Be en person med tillräcklig kompetens att granska tillämpningen och ange källor med datum. Leverantören kan bidra med fakta om sin verksamhet, men dess standardtext är inte ett självständigt beslut för er överföring. En uppgift om att leverantören aldrig fått en myndighetsbegäran behöver sättas i sitt sammanhang och kan inte ensam bevisa att problematisk rätt saknar betydelse.

5. Koppla varje lucka till ett fungerande skydd

Skriv vilken brist ni försöker hantera innan ni väljer åtgärd. Om problemet är att mottagaren kan tvingas lämna ut läsbart innehåll måste skyddet fungera mot just den möjligheten. Kryptering under transport löser inte åtkomst till klartext efter mottagandet. Ett löfte att alltid underrätta er kan begränsas av tillämplig rätt.

EDPB:s slutliga rekommendationer 01/2020 ger en arbetsgång i sex steg: kartlägg överföringar, välj stöd, bedöm effektiviteten, välj eventuella kompletterande åtgärder, genomför nödvändiga procedurer och ompröva skyddet. Om effektiva åtgärder inte kan uppnås ska överföringen inte påbörjas eller fortsätta på den grunden. Rekommendationerna är stöd för bedömningen, inte ett färdigt godkännande av varje teknisk produkt.

Fråga i granskningen Underlag att begära Konsekvens för beslutet
Kan mottagaren dekryptera innehållet? Teknisk beskrivning av nyckelåtkomst och drift Bedöm krypteringen mot den faktiska åtkomstrisken
Kan supporten klara arbetet utan verkliga kunddata? Felsökningsprov med syntetiskt underlag Pröva om överföringen kan begränsas eller undvikas
Kan en kod återkopplas till en person? Beskrivning av kompletterande data och åtkomst Utred pseudonymiseringens verkan i sammanhanget
Går data vidare till andra mottagare? Aktuell kedja över mottagare och länder Utvidga analysen till de relevanta leden

Detaljer om nycklar och ändpunkter finns i krypteringsguiden. Om ni använder pseudonymisering måste bedömningen också ta hänsyn till andra identifieringsmöjligheter. Att ta bort namn lämnar ofta kvar information som kan kopplas till människor.

6. Fatta ett avgränsat beslut

Beslutet ska säga vilken överföring som prövats och vilka förutsättningar som måste vara uppfyllda. Undvik ”leverantören är GDPR-godkänd”. Skriv i stället exempelvis att en angiven tjänst, mottagare, datamängd och konfiguration får användas under dokumenterade villkor. Öppna frågor som påverkar lagligheten ska lösas före start.

Beslutsexempel A – åtkomst begränsas före nytt ställningstagande. I supportprojektet visar ett prov att felsökning kan ske med ett reproducerat fel och syntetiska uppgifter. Den planerade åtkomsten till kundernas ärenden aktiveras inte. EES-teamet tar fram felbeskrivningar utan kundinnehåll och granskar bilagorna före överlämning. Projektet dokumenterar fortfarande vilka personuppgifter, exempelvis supportkontakters namn, som kan förekomma i det nya flödet och bedömer dessa separat. Det ursprungliga flödet har undvikits, inte godkänts med ett nytt namn.

Beslutsexempel B – uppstart skjuts upp. Ett annat projekt kräver att mottagaren läser fullständiga personalakter. Den rättsliga granskningen har identifierat en skyddsbrist, och den föreslagna krypteringen hjälper inte eftersom mottagaren har nyckelåtkomst. Projektägaren dokumenterar att det saknas visad effektiv lösning. Uppstarten stoppas medan alternativa mottagare, arbetsmetoder eller tekniska begränsningar utreds. Beslutet gäller de angivna förutsättningarna och är inte ett generellt omdöme om alla tjänster i ett visst land.

7. Genomför och kontrollera villkoren

Tilldela varje villkor en ansvarig, ett slutdatum och ett bevis. Om supporten ska vara avstängd från ett visst område behöver någon kontrollera faktiska roller och åtkomst, inte bara spara ett mejl från säljaren. Om exporter ska filtreras behöver ni prova även felaktiga bilagor, fritext och reservrutiner.

Koppla relevanta villkor till biträdesavtalet, säkerhetsbilagan och den interna beställningen. Se till att ändringar i tjänsten inte kan upphäva villkoren utan granskning. Uppdatera registerförteckningen och informationen till registrerade när det behövs.

Lagra analysen med versionsnummer, beslutsdatum, källor och hänvisning till den kontrollerade konfigurationen. Dokumentera även vem som får stoppa överföringen när en förutsättning brister. Ett godkännande som ingen kan omsätta i en driftåtgärd är svårt att upprätthålla.

En enkel kontrollista inför start kan innehålla fyra bevis: signerad avtalsversion, daterad rättslig bedömning, tekniskt kontrollresultat och namngiven ansvarig för fortsatt uppföljning. Den som fattar beslutet ska kunna hitta alla fyra utan att behöva gissa vilken mejltråd som är aktuell. Om ett avtal hänvisar till bilaga 2 men den tekniska rapporten avser en äldre bilaga behöver skillnaden lösas.

Prova även stoppvägen. Kan ni återkalla supportåtkomst utan att samtidigt förlora tillgång till era egna uppgifter? Vem kontaktar leverantören, och hur hanteras pågående ärenden? Spara ett besked om dessa praktiska frågor tillsammans med beslutet. Då kan ett framtida behov att pausa överföringen hanteras med förberett ansvar och tydliga konsekvenser för verksamheten.

8. Ompröva när verkligheten ändras

Bestäm lämpliga intervall och händelser som utlöser ny granskning. Relevanta förändringar kan vara ny lagstiftning, domstolsavgöranden, nya underbiträden, ändrad supportåtkomst eller ett förändrat certifieringsomfång när ett adekvansbeslut används. EDPB anger lämpliga intervall; det finns inte en allmän regel i dessa rekommendationer om att varje TIA måste förnyas exakt årligen.

Gör bevakningen praktisk. Avtalsansvarig tar emot leverantörens ändringsmeddelanden, tjänsteägaren identifierar ändrad användning och den juridiska funktionen bedömer relevanta rättsliga förändringar. Sätt en ersättare om ordinarie ansvarig är frånvarande. Ange vilken överföring som ska pausas medan en väsentlig osäkerhet utreds.

Bedöm separat hur länge analysunderlaget behöver sparas. Det ska gå att förstå ett tidigare beslut utan att ni rutinmässigt behåller onödiga kopior av överförda personuppgifter. Anpassa dokumentationens bevarande till ansvar, tillämpliga regler och organisationens behov; anta inte en generell femårsfrist för varje TIA. Ett komplett underlag kännetecknas av att slutsatsen kan följas tillbaka till aktuella fakta, inte av ett visst antal sidor.

L
Skriven av
Legiscope
Legiscope

Omsätt vägledningen i praktiken

Se hur Legiscope kopplar samman integritetsregister, källmaterial och granskningsstyrt arbete.

Boka en anpassad demo
Fortsätt läsa

Relaterade artiklar

01Dataskydd

Allmän handling och GDPR: pröva utlämnande och säker leverans

En begäran om en allmän handling ska inte avslås bara för att handlingen innehåller personuppgifter. Myndigheten behöver identifiera handlingen, bedöma om den är allmän, pröva eventuell sekretess och…

8 september 2026
02Dataskydd

Ändamålsbegränsning: pröva ny användning av personuppgifter

”Vi har redan uppgifterna” är inte ett tillräckligt skäl för att använda dem i ett nytt projekt. Kunduppgifter som samlats in för support kan vara praktiskt användbara för försäljning, produktanalys…

8 september 2026
03Dataskydd

Anmäla personuppgiftsincident till IMY: 72-timmarsregeln

En personuppgiftsincident ska anmälas till IMY utan onödigt dröjsmål och senast inom 72 timmar från det att du fått kännedom om den, om incidenten sannolikt medför en risk för de registrerades…

7 juli 2026
04Dataskydd

Anonymisering: bedöm identifierbarhet före delning

Att anonymisera personuppgifter innebär mer än att ta bort namn och personnummer. En kombination av ort, tid, befattning och ovanliga händelser kan räcka för att någon ska kunna identifieras. Bedöm…

8 september 2026
05Dataskydd

Ansvarsskyldighet: koppla GDPR-beslut till bevis

Ansvarsskyldighet innebär att den personuppgiftsansvarige både ska följa dataskyddsprinciperna och kunna visa hur de följs. Ett användbart underlag kopplar därför samman ändamål, beslut, genomförd…

8 september 2026
06Dataskydd

Är en IP-adress en personuppgift? Bedöm det konkreta dataflödet

En IP-adress kan vara en personuppgift även när den som läser adressen inte direkt ser ett namn. Bedömningen beror på om informationen rör en fysisk person som är identifierad eller kan identifieras…

8 september 2026
07Dataskydd

Artikel 14: informera när personuppgifter kommer från andra

Artikel 14 GDPR styr informationen när personuppgifter kommer från någon annan än personen själv. Det kan vara en samarbetspartner, en offentlig webbplats, en leverantör av kontaktuppgifter eller en…

8 september 2026
08Dataskydd

Återställningsplan för IT: bestäm RTO, RPO och ordningsföljd

En återställningsplan för IT beskriver hur verksamheten får tillbaka fungerande system och användbara uppgifter efter ett avbrott. Den behöver ange prioritering, beroenden, ansvar och kontroll av…

8 september 2026