Dataportabilitet vid byte av affärssystem: vad gäller?

Varför dataportabilitet aktualiseras vid byte av affärssystem

Affärssystem rymmer både affärsdata (ordrar, artiklar, avtal, transaktioner) och personuppgifter (kundkontakter, kontaktpersoner hos leverantörer, anställda, löneunderlag). GDPR har gällt i hela EU sedan 25 maj 2018 och är grunden för skyddet av personuppgifter enligt Advokatsamfundets vägledning. Personuppgiftsdelen lyder därför under dataskyddsreglerna även vid ett rent systembyte: överföringen är i sig en behandling av personuppgifter.

Personuppgiftsansvaret stannar hos er verksamhet. Ett systembyte ändrar inte ansvaret, så projektet måste hantera teknik och juridik samtidigt: vilka uppgifter som får föras över, vilka som ska gallras i stället för att migreras och hur leverantörskedjan ser ut efter bytet.

Kartlägg personuppgifterna i CRM-, sälj- och lönesystem

Börja med att inventera IT-stödet och personuppgiftsbehandlingen i varje system. En branschpublikation lyfter fram att IT-stöd och personuppgiftsbehandling i CRM-, sälj- och lönesystem bör ses över, och att en huvudprojektledare bör utses. Rollen blir navet mellan verksamhet, IT och dataskyddsombud.

Inventeringen bör per system lista kategorier av registrerade (kunder, kontaktpersoner, anställda, kandidater), vilka fält som innehåller personuppgifter, ändamålet, var uppgifterna lagras, mottagare och gallringsregel. Ta också med system som sällan kallas affärssystem men ändå innehåller personuppgifter: e-post, supportverktyg, integrationer, rapporteringslager och säkerhetskopior.

Resultatet avgör portabilitetens omfattning. Finns samma person i flera system måste ni bestämma vilket system som är källa och vilket som är mottagare; annars kan dubbletter med olika innehåll föras över.

Samtycke och rättslig grund när uppgifter flyttas

All behandling av personuppgifter kräver en rättslig grund. Vid ett systembyte blir en ny leverantör mottagare och lagringsplatsen kan ändras. Sådana förändringar ska rymmas inom gällande grund och ändamål, eller leda till en ny bedömning. Ska det nya systemet användas för något nytt – analys eller profilering som inte gjordes tidigare – är det ett nytt ändamål med eget stöd.

Samtycke är en möjlig grund, men sällan praktisk för affärssystem: det kan återkallas och uppgifterna måste då hanteras därefter. Vad som är ett giltigt samtycke har också tillsynsmyndigheternas uppmärksamhet – EDPB behandlar frågan i yttrande 08/2024 efter begäran från tillsynsmyndigheterna i Nederländerna, Norge och Tyskland (Hamburg).

När nationell rätt eller unionsrätt ligger till grund för behandlingen gäller särskilda krav. Departementsskrivelsen DS 2017:19 om anpassningar till dataskyddsförordningen påpekar att artikel 6.3 kräver att den rättsliga grunden uppfyller vissa villkor. Vilar verksamheten på lag eller myndighetsbeslut bör den grunden – inte samtycke – bära behandlingen även efter bytet.

Viktiga regelverk och riktlinjer för dataportabilitet i Sverige

Olika system, olika rutiner – vanliga compliance-problem

Ett vanligt GDPR-problem är att verksamheter gör olika i olika system. En studie om compliance-utmaningar med dataskyddsförordningen beskriver att man gör på ett sätt i ett system och ett annat sätt i ett annat. Vid ett systembyte blir skillnaden konkret: samma person kan vara kund i CRM-systemet, kontaktperson i avtalssystemet och anställd i lönesystemet, med olika fältnamn, begrepp och gallringsregler.

En överföring kan därför inte vara en tabellkopia. Den kräver fältmappning: vad varje fält i det gamla systemet motsvarar i det nya, och vad som saknar motsvarighet och ska lämnas kvar eller gallras. Invändningar mot behandling, återkallade samtycken och spärrade poster tappas lätt bort om de finns i fritextfält eller i handläggarens minne i stället för i strukturerad form.

Odokumenterade undantag – en kalkylarkslista, en manuell rutin för känsliga ärenden – gör också att det nya systemet kan bli mer öppet än det gamla. Behörighetsmodellen bör sättas före migreringen, inte efter.

Bestäm vad som ska flyttas, bevaras eller gallras

Hanteringsanvisningar låter er bedöma per handlingstyp. Stockholms stads hanteringsanvisningar från maj 2022 har kolumner som process, handlingstyp, diarieföra i, bevara/gallra, gallringsbeslut, sekretess, personuppgifter, förvara, förvara analogt och arkivera. Matrisen kan användas som mall för ett affärssystem: för varje uppgiftstyp bestäms om den ska migreras, bevaras eller gallras, enligt vilket beslut och med vilken sekretessmarkering.

Dela upp innehållet i tre grupper. Flytta: uppgifter med pågående ändamål som verksamheten behöver i det nya systemet. Bevara: uppgifter som enligt arkivregler eller annan författning ska bevaras men inte behöver ligga i produktionssystemet – de kan lyftas till en arkivlösning. Gallra: uppgifter vars ändamål har upphört och där ingen bevarandeskyldighet finns; gallra dem i källsystemet före eller i samband med migreringen, flytta dem inte "för säkerhets skull".

Dokumentera gallringsbeslut och sekretessbedömning per uppgiftstyp innan data flyttas. Sekretessen styr också utformningen: uppgifter som omfattas av sekretess ska inte bli tillgängliga för fler i det nya systemet än i det gamla.

Bedöm leverantören och molntjänstens digitala suveränitet

Ligger affärssystemet helt eller delvis i molnet ingår leverantörsbedömningen i dataportabiliteten. En guide från Publitech beskriver hur kommuner och regioner kan bedöma molnleverantörer på fem nivåer, från datalagring till AI. Nivåerna strukturerar frågor som annars lätt stannar vid teknik: var data ligger, vem som kan komma åt den och vad den får användas till.

Frågor att få skriftliga svar på före avtal: I vilka länder lagras uppgifterna, och vilka underleverantörer ingår i kedjan? Vilka rättsliga möjligheter har myndigheter i de länderna att begära ut uppgifterna? Används kunddata för att träna eller förbättra AI-modeller, och i så fall med vilket stöd? Hur sker supportåtkomst till produktionsdata, och vem förvaltar krypteringsnycklarna?

Portabilitet vid avslut är en egen avtalsfråga: i vilket format och inom vilken tid får ni ut era data om ni lämnar tjänsten, och vad gäller eventuella kostnader för exporten? Ett personuppgiftsbiträdesavtal ska reglera instruktioner, underbiträden, incidenthantering och radering. I molnupphandlingsdebatten finns en motriktning: på samma sida återges entreprenören Amer Mohammeds tips till kommuner – våga testa och skippa tidskrävande kravspecifikationer. Det arbetssättet ställer högre krav på att testmiljön avgränsas och att personuppgiftsfrågorna är besvarade innan skarp data flyttas.

Dokumentation, sekretess och förvaring vid bytet

Behandlingsregistret måste uppdateras vid systembytet: nya mottagare och underbiträden, ändrad lagringsplats, ändrade gallringsrutiner och eventuellt ändrat ändamål. Det bör också framgå vilken rättslig grund som bär behandlingen efter bytet och vilken roll den nya leverantören har.

Migrationen skapar egna behandlingar som ska dokumenteras och avslutas. Extraktionsfiler, testmiljöer med kopior av produktionsdata och tillfälliga arbetskopior ska begränsas i tid och åtkomst samt gallras när överföringen är verifierad. Sådana kopior blir ofta kvar utanför både det gamla och det nya systemet, utan ägare och gallringsregel.

Sekretess- och förvaringskrav följer uppgifterna genom hela bytet. Ska något bevaras ska det bevaras i rätt form, på rätt plats och med rätt metadata – inte nödvändigtvis i det nya affärssystemet. En avvecklingsplan för det gamla systemet, med beslut om vad som exporteras, arkiveras och raderas, hör till projektets slutfas.

Checklista inför bytet