TIA och GDPR: praktisk guide för dataskyddsansvariga

En Transfer Impact Assessment (TIA) är den skriftliga, fall-för-fall-bedömning som exportören måste genomföra innan personuppgifter överförs till ett tredjeland med stöd av ett artikel 46-verktyg, till exempel standardavtalsklausuler (SCC) eller bindande företagsregler (BCR). Bedömningen kräver tre saker:

Kartlägg vilka lagar och vilken myndighetspraktik som gäller i mottagarlandet och avgör om de underminerar skyddet i transferverktyget.
Identifiera om kompletterande åtgärder (tekniska, organisatoriska eller avtalsbaserade) kan kompensera för eventuella brister.
Fatta ett dokumenterat beslut: genomför överföringen med åtgärder, begränsa den eller avstå helt.

TIA-kravet härstammar direkt från Schrems II-domen (C-311/18) och förtydligas i EDPB:s rekommendationer 01/2020 samt CNIL:s TIA-guide från januari 2025. Överförs data till ett land med ett giltigt adekvatbeslut från EU-kommissionen behövs ingen TIA för den specifika överföringen.

Viktiga insikter

En korrekt genomförd TIA kräver kartlagda flöden, verifierade kompletterande åtgärder och en bevislåda som håller vid tillsynsgranskning.

Punkt	Detaljer
TIA krävs vid artikel 46-verktyg	Genomför TIA för varje överföring till tredjeland utan adekvatbeslut, innan överföringen startar.
Schrems II sätter ribban	Exportören måste verifiera mottagarlandets lagar och praktik, inte bara underteckna SCC.
Tekniska åtgärder väger tyngst	EU-kontrollerade krypteringsnycklar (BYOK/HSM) och JIT-åtkomst är starkare skydd än avtalsklausuler.
Bevislådan är avgörande	KMS-loggar, accessloggar, SOC-rapporter och SCC-bilagor måste finnas och vara aktuella.
Evertrust för TIA-stöd	Evertrust erbjuder workshops, TIA-leverans, implementeringsstöd och Trustview för digital bevishantering.

Innehållsförteckning

Vad är TIA GDPR och varför krävs den?
När måste ni göra en TIA?
Hur genomför ni en TIA steg för steg?
Vilka kompletterande åtgärder fungerar i praktiken?
Hur visar ni att åtgärderna faktiskt är i drift?
Vad vill tillsynsmyndigheten se i er dokumentation?
Vilka är de vanligaste misstagen vid TIA-genomförande?
Vilka mallar och verktyg bör ni använda?
Vad erfarna rådgivare ser att organisationer missar
Evertrust stödjer er genom hela TIA-processen
Perspektiv: det som TIA-guider sällan säger rakt ut
Källor

En TIA är inte ett standardformulär som fylls i en gång. Det är en juridisk och teknisk analys som exportören, det vill säga den personuppgiftsansvarige eller personuppgiftsbiträdet som skickar data, måste göra för varje relevant överföringsflöde.

Grunden finns i GDPR artikel 44–50. Artikel 46 listar de transferverktyg som kan användas när inget adekvatbeslut finns: SCC, BCR, uppförandekoder, certifieringar och ad hoc-avtal. Problemet som Schrems II blottlade är att ett transferverktyg på pappret inte räcker om mottagarlandets lagstiftning i praktiken tvingar importören att ge myndigheter tillgång till data utan att EU-registrerade kan utkräva rättigheter.

CJEU slog i Schrems II fast att exportören måste verifiera om tredjelandets lagar och praxis underminerar det skydd som artikel 46-verktyget ger, och att exportören vid behov måste lägga till kompletterande åtgärder eller avstå från överföringen. Det räcker inte att hänvisa till att SCC är undertecknade.

CNIL bekräftar att TIA ska utföras av exportören med importörens hjälp, och att den ska vara klar innan överföringen påbörjas. EDPB:s vägledning täcker även uppförandekoder som transferverktyg och specificerar vilka garantier sådana koder måste innehålla för att räknas som lämpliga skyddsåtgärder.

Europeiska kommissionen understryker skillnaden: adekvatbeslut undantar från ytterligare skyddsanalys, medan artikel 46-verktyg kräver att exportören själv verifierar att skyddsnivån är likvärdig EU:s.

När måste ni göra en TIA?

Svaret är kortare än många tror: en TIA krävs varje gång ni förlitar er på ett artikel 46-verktyg för en överföring till ett land utan adekvatbeslut. Det gäller oavsett om ni är personuppgiftsansvarig eller biträde.

Situationer som utlöser TIA-krav:

Ni använder SCC, BCR, uppförandekoder eller certifieringar som grund för en överföring till ett tredjeland.
En molntjänst-leverantör (SaaS, IaaS, PaaS) har underbiträden i länder utan adekvatbeslut, till exempel USA, Indien eller Kina.
Fjärrsupport eller drift sköts av personal utanför EU/EES med åtkomst till personuppgifter.
Data speglas eller säkerhetskopieras till servrar i ett tredjeland.
En vidareöverföring sker, det vill säga importören i ett tredjeland skickar vidare data till ett annat tredjeland.

När TIA inte krävs:

Överföringen sker till ett land som täcks av ett giltigt adekvatbeslut, till exempel Japan, Sydkorea eller Schweiz.
Undantaget i artikel 49 är tillämpligt, men det tolkas restriktivt och får inte användas som rutin.

Tre konkreta scenarier:

Moln-SaaS med globalt underbiträde: Er HR-plattform har en underbiträdeskedja som inkluderar ett datacenter i USA. Ni behöver en TIA för det flödet, även om er primärleverantör är etablerad i EU.
Fjärrsupport: En leverantörs supportteam i Indien har åtkomst till er produktionsmiljö för felsökning. Varje sådan åtkomstväg är ett överföringsflöde som kräver bedömning.
Datalagring utanför EES: Ni lagrar backup-kopior i ett datacenter i Singapore utan adekvatbeslut. TIA krävs för det flödet.

Hur genomför ni en TIA steg för steg?

Metodiken nedan följer EDPB:s rekommenderade flöde och CNILs processbeskrivning. Varje steg har en tydlig ansvarspunkt.

Steg 1: Kartlägg överföringsflödena

Identifiera alla flöden där personuppgifter lämnar EU/EES. Dokumentera datatyper (känsliga uppgifter kräver extra noggrannhet), kategorier av registrerade, mottagare och samtliga underbiträden i kedjan. Ansvar: DPO och IT/arkitektur.

Vanliga blinda fläckar är underbiträdeskedjor i SaaS-avtal och loggsystem som skickar data till tredjepartsplattformar. Kartläggningen är inte klar förrän ni kan rita ett komplett flödesschema med alla noder utanför EU/EES.

Steg 2: Beskriv transferverktyget och kontrollera formalia

Vilket artikel 46-verktyg används? Är SCC-bilagorna korrekt ifyllda och speglar de de faktiska dataflödena? Är BCR godkänd av behörig tillsynsmyndighet? Ansvar: juridik och leverantörsansvarig.

Steg 3: Bedöm mottagarlandets rättsliga och praktiska risker

Det här är kärnan i TIA-arbetet. Ni behöver analysera:

Nationell lagstiftning om statlig tillgång till data (underrättelselagar, säkerhetslagar).
Myndighetspraktik: finns det dokumenterade fall av tvingad datautlämning?
Transitrisker om data passerar ytterligare länder.
Importörens möjlighet att meddela exportören vid en myndighetsförfrågan.

Ansvar: juridik, med stöd av DPO och CISO.

Steg 4: Identifiera och bedöm kompletterande åtgärder

EDPB rekommenderar en kombination av tekniska, organisatoriska och avtalsbaserade åtgärder. Bedöm varje åtgärds faktiska effektivitet i det specifika sammanhanget, inte bara på pappret. Ansvar: CISO och juridik gemensamt.

Steg 5: Fatta och dokumentera beslut

Tre möjliga utfall:

Genomför överföringen med identifierade åtgärder och en tidsplan för implementering.
Begränsa överföringen, till exempel till specifika datatyper eller åtkomstfönster.
Avstå från eller suspendera överföringen om effektiva åtgärder saknas.

Dokumentera vem som fattat beslutet, på vilken grund och när omprövning ska ske. Ansvar: DPO och verksamhetsansvarig.

Steg 6: Implementera, bygg bevislåda och planera omprövning

Åtgärder som inte kan bevisas existerar inte ur tillsynsmyndighetens perspektiv. Samla tekniska konfigurationer, loggar och avtal i en strukturerad bevislåda. Planera omprövning minst en gång per år eller vid väsentliga förändringar.

TIA-steg	Ansvarig	Bevis som krävs
Kartläggning av flöden	DPO, IT	Flödesschema, registerförteckning
Transferverktyg och formalia	Juridik	Signerade SCC, BCR-godkännande
Rättslig landsbedömning	Juridik, DPO	Landsanalys, rättskällor
Kompletterande åtgärder	CISO, juridik	Teknisk konfiguration, avtalsdokument
Beslut och dokumentation	DPO, verksamhet	Beslutsdokument med datum och ansvar
Bevislåda och omprövning	DPO, CISO	Loggar, KMS-konfig, SLA-bilagor

Vilka kompletterande åtgärder fungerar i praktiken?

Kompletterande åtgärder är inte ett smörgåsbord där ni väljer fritt. EDPB är tydliga: om ingen åtgärd kan kompensera för att mottagarlandets lagar tvingar importören att ge myndigheter tillgång till data i klartext, ska överföringen inte ske.

Tekniska åtgärder:

Kryptering med EU-kontrollerade nycklar (BYOK, externt nyckelhanteringssystem eller HSM). Nyckeln stannar hos exportören; importören kan inte dekryptera data på myndighetsbegäran.
Klientsidekryptering, där data krypteras innan den lämnar EU och importören aldrig ser klartext.
Pseudonymisering kombinerat med att nyckeln hålls i EU.
Just-in-time-åtkomst (JIT) för support, med detaljerad loggning av varje session.

Organisatoriska åtgärder:

Platsbindning som begränsar var data fysiskt kan lagras och bearbetas.
Begränsade supportfönster med förhandsgodkännande och tvåpersonsgodkännande för åtkomst.
Dataminimering: exportera bara de uppgifter som faktiskt behövs för ändamålet.
Retention-styrning kopplad till lagringstider enligt GDPR så att data inte lagras längre än nödvändigt i tredjelandet.

Avtalsbaserade åtgärder:

SCC-bilagor som exakt speglar de faktiska dataflödena, inklusive underbiträdeskedjor.
Flow-down-krav till samtliga underbiträden i kedjan.
SLA-krav på att importören levererar ett bevispaket (evidence pack) vid begäran.
Förbud mot oannonserad failover till datacenter i länder som inte täcks av TIA.

Proffstips: Tekniska åtgärder är generellt starkare än avtalsbaserade när mottagarlandets lagar kan tvinga importören att bryta avtalet. En SCC-klausul skyddar inte mot en lagstadgad utlämningsskyldighet, men en EU-kontrollerad krypteringsnyckel gör det.

En situation där åtgärder sällan räcker är när importören har tillgång till data i klartext och är föremål för lagstiftning som ger myndigheter bred och svårkontrollerad tillgång, utan möjlighet till rättslig prövning för de registrerade. EDPB:s rekommendationer listar sådana scenarier explicit.

Hur visar ni att åtgärderna faktiskt är i drift?

Det räcker inte att beskriva åtgärder i TIA-dokumentet. Tillsynsmyndigheter förväntar sig en beviskedja som visar att åtgärderna är konfigurerade, aktiva och kontrollerade.

Bevislådan bör innehålla:

KMS-konfiguration med dokumentation av nyckelrotation och åtkomstkontroll.
Accessloggar från JIT-supportworkflows, inklusive tidsstämplar och användar-ID.
SOC 2 Type II-rapporter eller motsvarande säkerhetsrapporter från importören.
Signerade SCC och DPA-bilagor med korrekt ifyllda appendix.
Incidentrapporter som visar hur eventuella myndighetsförfrågningar hanterades.
SLA-dokumentation som specificerar leverantörens skyldighet att tillhandahålla bevispaket.

Tekniska exempel i praktiken:

BYOK-konfiguration med EU-nyckelkontroll innebär att ni skapar och hanterar krypteringsnycklar i ett nyckelhanteringssystem som ni kontrollerar, till exempel Azure Key Vault med Managed HSM i en EU-region eller AWS CloudHSM med EU-placering. Importören kan lagra krypterad data men kan inte dekryptera den utan er nyckel. Dokumentera konfigurationen, nyckelrotationsschema och vem som har åtkomst till nyckelhanteringssystemet.

JIT-supportworkflow fungerar så att supportpersonal i tredjelandet begär åtkomst per ärende, åtkomsten godkänns av en EU-baserad ansvarig, sessionen loggas i realtid och åtkomsten återkallas automatiskt när ärendet stängs. Loggar exporteras till ett EU-kontrollerat system.

Proffstips: Designa SLA:et med leverantören så att de är skyldiga att leverera ett bevispaket inom 48 timmar vid en tillsynsförfrågan. Utan den klausulen riskerar ni att inte kunna bevisa att åtgärderna fungerade vid den tidpunkt som tillsynsmyndigheten granskar.

Tillsynsmyndigheter kontrollerar ofta om KMS-konfigurationen faktiskt förhindrar importörens åtkomst, om loggar är kompletta och om SCC-bilagorna stämmer med de faktiska flödena. Förbered svar på dessa frågor innan ni behöver dem.

Vad vill tillsynsmyndigheten se i er dokumentation?

Dokumentationskravet följer av GDPR:s ansvarsskyldighet (artikel 5.2). En TIA som inte kan uppvisas är juridiskt sett lika med ingen TIA.

Obligatoriska dokument:

Fullständig TIA-rapport med datum, version och signaturer.
Besluts- och ansvarsmatris som visar vem som godkänt vad och när.
Tekniska konfigurationsdokument (KMS, HSM, nätverkssegmentering).
Signerade avtal: SCC, DPA och eventuella tillägg.
Bevispaket från leverantören (SOC-rapporter, penetrationstestresultat, loggar).

Versionshantering och retention:

Spara varje version av TIA-rapporten med datum och ändringslogg. Bevislådan bör lagras minst lika länge som den aktuella behandlingen pågår, plus den tid tillsynsmyndigheten kan inleda ett ärende. Åtkomstkontroll till bevislådan ska dokumenteras.

Utlösare för omprövning:

Lagändringar i mottagarlandet, till exempel ny underrättelselagstiftning.
Ny leverantör eller nytt underbiträde i kedjan.
En incident där tredjelandspersonal haft åtkomst till data utanför godkänd process.
Minst en gång per år, oavsett om något förändrats.

EDPB ser TIA som en levande process och betonar att omprövning vid väsentliga förändringar är ett krav, inte en rekommendation.

Vid en tillsynsförfrågan ska ni kunna presentera en sammanhängande beviskedja: från det ursprungliga beslutet, via implementerade åtgärder, till löpande kontroller. En tidslinje med versionsnummer och ansvariga personer gör det enkelt att följa.

Vilka är de vanligaste misstagen vid TIA-genomförande?

Dessa fel dyker upp återkommande och leder antingen till att TIA underkänns eller att en överföring måste stoppas i efterhand.

Förlita sig på leverantörens marknadsföringspåståenden. Att en leverantör påstår att “data är säkra” eller “vi är GDPR-compliant” är inte ett bevis. Ni behöver KMS-loggar, SOC-rapporter och faktiska konfigurationsdokument.
Underskatta underbiträdeskedjan. Många TIA-fel beror på att vidareöverföringar inte kartlagts. Er primärleverantör kanske är EU-baserad, men deras underbiträden kan finnas i länder utan adekvatbeslut. Flow-down-kravet måste nå hela kedjan.
Utebliven omprövning efter förändringar. En TIA som gjordes för tre år sedan och aldrig uppdaterats täcker inte en leverantör som sedan dess lagt till ett datacenter i ett nytt land eller ändrat sin supportmodell.
Använda artikel 49-undantag som rutin. Undantagen i artikel 49, till exempel samtycke eller nödvändighet för avtalets fullgörande, är avsedda för enstaka, icke-repetitiva situationer. Att använda dem för löpande affärsöverföringar är ett välkänt tillsynsproblem som EDPB:s beslut om WhatsApp illustrerar tydligt.
SCC-bilagor som inte speglar verkligheten. Bilagorna måste beskriva de faktiska dataflödena, inte en generisk mall. En tillsynsmyndighet som ser att bilaga 1 inte stämmer med er registerförteckning ifrågasätter hela TIA:n.

Vilka mallar och verktyg bör ni använda?

Börja med de officiella källorna. De är gratis, auktoritativa och direkt tillämpliga.

Officiella mallar och vägledningar:

EDPB Recommendations 01/2020: sexstegsmetodiken och listan över supplementary measures. Använd den som metodramverk och kontrollera att er TIA-process täcker varje steg.
CNIL TIA-guide (januari 2025): praktisk processbeskrivning med tydliga steg och ansvarsfördelning. Särskilt användbar för att strukturera dokumentationen.
EU-kommissionens resurser om tredjelandsöverföringar: förklaring av transferverktyg och adekvatbeslut. Bra startpunkt för att avgöra vilket verktyg som är tillämpligt.
EDPB:s riktlinjer om uppförandekoder som transferverktyg: relevant om ni överväger uppförandekoder som alternativ till SCC.

Praktiska checklistor:

Kartläggningschecklista: lista alla system som behandlar personuppgifter, identifiera var data lagras och bearbetas, kartlägg underbiträdeskedjor och markera alla noder utanför EU/EES.
Bevispackchecklista: KMS-konfiguration, nyckelrotationslogg, accessloggar, SOC-rapport, signerade SCC/DPA, SLA med evidence pack-krav, incidentlogg.
Beslutsträd: adekvatbeslut? Nej → artikel 46-verktyg? Ja → TIA krävs → kompletterande åtgärder effektiva? Nej → avstå från överföring.

Verktygsval:

GRC-plattformar är värdefulla för att hantera versioner av TIA-dokumentation, koppla bevis till specifika kontroller och automatisera påminnelser om omprövning. Evertrusts plattform Trustview är ett exempel på ett sådant verktyg, byggt för att hantera GDPR-efterlevnad inklusive TIA-dokumentation och bevislagring i ett strukturerat format.

Vad erfarna rådgivare ser att organisationer missar

De flesta organisationer lägger för mycket tid på att skriva TIA-rapporten och för lite tid på att bygga bevislådan. En välformulerad rapport utan tekniska bevis håller inte vid granskning.

Prioritera toppriskflödena först. Börja med de flöden som involverar känsliga personuppgifter, hälsodata, finansiell information eller uppgifter om barn, och de leverantörer som har mest frekvent åtkomst till er produktionsmiljö. En organisation med hundra leverantörer behöver inte göra en fullständig TIA för alla på en gång; riskbaserad prioritering är både tillåten och nödvändig.

Bygg återanvändbara mallar tidigt. En välstrukturerad TIA-mall med fördefinierade sektioner för landsanalys, åtgärdsbedömning och beslutsdokumentation sparar veckor av arbete när ni ska hantera tio leverantörer i stället för en. Koppla mallen till er registerförteckning så att uppdateringar i ett system automatiskt flaggar för omprövning i det andra.

Definiera roller och SLA internt. DPO äger processen, CISO äger de tekniska bevisen och leverantörsansvarig äger avtalsdokumentationen. Utan tydliga ägarskap hamnar TIA-arbetet i ett vakuum där alla tror att någon annan hanterar det. Sätt ett internt SLA: leverantörsansvarig ska leverera bevispaket inom fem arbetsdagar vid en ny TIA eller omprövning.

Evertrust stödjer er genom hela TIA-processen

En genomförd TIA är mer än ett juridiskt krav. Det är beviset att er organisation faktiskt kontrollerar vart personuppgifter tar vägen och under vilka villkor.

Evertrust erbjuder strukturerat stöd för organisationer som behöver genomföra eller kvalitetssäkra sin TIA-process. Ett typiskt uppdrag börjar med en workshop där vi kartlägger era överföringsflöden och identifierar toppriskerna, följt av en TIA-leverans med fullständig dokumentation och bevispackstruktur. Därefter stödjer vi implementeringen av kompletterande åtgärder, inklusive SCC-bilagearbete, leverantörsgranskning och teknisk bevisning. Årsöversynen ingår som en naturlig del av ett löpande uppdrag.

För organisationer som vill hantera TIA-dokumentation och bevislagring digitalt erbjuder vi även Trustview-plattformen, som är byggd för GDPR-efterlevnad inklusive versionsstyrning och kontrollspårning. Läs gärna vår analys av Vattenfalls GDPR-böter för ett konkret exempel på vad bristande dokumentation kan kosta. Ta kontakt med Evertrust för att diskutera hur ett TIA-uppdrag kan se ut för er organisation.

Perspektiv: det som TIA-guider sällan säger rakt ut

Det finns en utbredd missuppfattning om vad en TIA faktiskt är till för. Många organisationer behandlar den som ett compliance-dokument, något som ska finnas i mappen om tillsynsmyndigheten knackar på. Det är fel utgångspunkt.

En TIA är ett beslutsunderlag. Den ska tvinga fram en ärlig bedömning av om er organisation faktiskt kan skydda de registrerades uppgifter när de lämnar EU. Om svaret är nej, är det rätta beslutet att inte genomföra överföringen, oavsett hur bekvämt det vore affärsmässigt.

Det som gör TIA-arbetet svårt är inte juridiken. EDPB:s sexstegsmodell är välstrukturerad och CNIL:s guide är tydlig. Det svåra är att organisationer sällan har den tekniska insyn i sina leverantörers infrastruktur som krävs för att göra en ärlig bedömning. En leverantör som inte kan visa er KMS-konfiguration, nyckelrotationsloggar och en tydlig förklaring av vilka anställda som har åtkomst till era data och från vilka länder, är en leverantör ni inte kan göra en trovärdig TIA för. Det är ett affärsbeslut, inte bara ett juridiskt problem.

En annan underskattad risk är att TIA-processen stannar hos DPO och juridik utan att CISO och IT är genuint involverade. Tekniska åtgärder som inte är konfigurerade och verifierade av säkerhetsteamet är inte åtgärder, de är önskemål. De bästa TIA-processer jag sett är de där DPO, CISO och leverantörsansvarig sitter i samma rum och gemensamt äger beslutet.

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.

Källor

Dessa källor är grunden för allt TIA-arbete och de dokument tillsynsmyndigheter förväntar sig att ni känner till.

Rekommendation

Artikel skapad av BabyLoveGrowth

Chatta med oss

Maila

Slå en signal

Glöm inte att hålla kontakten