Syftet med denna sida är att skapa en gemensam förståelse för juridiska och säkerhetsmässiga aspekter på systemintegration av personuppgifter. Målsättningen är att underlätta diskussion mellan informationsägare, integrationsarkitekter och andra inblandade när man värderar olika lösningsförslag för integration.
Denna sida är under arbete!
Begrepp och termer
Syftet med följande modell är att etablera en gemensam förståelse för de begrepp och termer som används.
Begreppsmodell
Modellen finns i 2c8.
Definitioner
Dessa begrepp förekommer ofta/alltid i diskussionen. De måste definieras och sättas i sammanhang:
Begrepp | Innebörd | Exempel |
|---|---|---|
Personuppgift | ||
Känsliga personuppgifter | Vissa personuppgifter är till sin natur särskilt känsliga och har därför ett starkare skydd. De kallas för känsliga personuppgifter. | Känsliga personuppgifter är uppgifter om
|
Extra skyddsvärd personuppgift | Ett personnummer anses vara en extra skyddsvärd personuppgift. | |
Extern aktör Extern part | En annan organisation än GU | |
Personuppgiftsbehandling Behandling | ||
Personuppgiftsansvarig (PUA) | Personuppgiftsansvarig är den organisation (till exempel aktiebolag, stiftelse, förening eller myndighet) som bestämmer för vilka ändamål uppgifterna ska behandlas och hur behandlingen ska gå till. | |
Personuppgiftsbiträde (PUB) | Personuppgiftsbiträde är den som behandlar personuppgifter för en personuppgiftsansvarigs räkning. Ett personuppgiftsbiträde och dess personal får enbart behandla personuppgifter enligt instruktion från den personuppgiftsansvariga. | |
Personuppgiftsbiträdesavtal (PUBA) Biträdesavtal | ||
General Data Protection Regulation (GDPR) Dataskyddsförordningen | ||
Lagring | ||
Överföring | ||
Uppgiftsminimering | ||
Rättslig grund | ||
Samtycke | ||
Allmänintresse | ||
Spridning |
Dessa begrepp är inte lika viktiga men ändå:
Begrepp | Innebörd | Exempel |
|---|---|---|
Dataskyddsombud | ||
Dataskyddsgruppen |
Interaktionsmönster
Följande är olika interaktionsmönster som kan användas för systemintegration.
Asynkron överföring (push)
Detta mönster bygger på att uppgifter skickas till mottagaren när de etableras/uppdateras. Mottagaren lagrar uppgifterna.
Tjänsten skickar ut ALLA uppgifter. Extern part behöver göra behandling i form av filtrering:
Lagra alla uppgifter
Sortera bort personer där extern part inte har rättslig grund för behandling (t.ex. personer som inte har lämnat samtycke)
Denna behandling görs på uppdrag av GU och regleras i PUBA. Anledningen till att den görs på uppdrag är att extern aktör saknar rättslig grund för filtreringen.
Följande bild visar infrastruktur och logiska ansvarsgränser för personuppgiftsbehandling vid asynkron överföring (push) från GU till en extern part:
Överföringen initieras av en uppdatering i källsystemet. Endast en delmängd av data i källsystemet får behandlas av extern part, men kriterierna för att avgöra detta är inte tillgängliga på GU. Därför överlåts ansvaret för denna filtrering till den externa parten.
Notera att GU har personuppgiftsansvar även för den behandling (filtrering) som görs av leverantören (enligt PUBA).
Det kan finnas problem med denna approach. Alla uppgifter kommer att skickas.
Här måste man bedöma om huruvida man litar på mottagaren eller inte. Vilken risk finns att uppgifterna missbrukas dvs att mottagaren bryter mot avtalet. Risk- och sårbarhetsanalys måste göras.
Exempel: Chalmers
Nuläge
Att vi gör filtrering och skickar uppgifter utan avtal innebär en risk att vi skickar uppgifter som inte är sanna.
Principer i GDPR som detta kan bryta mot: Riktighet (är personen relevant för Chalmers?), Konfidentialitet, Uppgiftsminimering (ej givet att uppgifterna absolut behövs)
Nyläge
Följande exempel illustrerar hur integration av Studiedeltagande kan ske från GU Ladok till Chalmers enligt ovanstående modell:
Synkron överföring
Pull / Request-Reply / on demand.
En extern part frågar GU. GU har kontroll över utlämnandet.
Följande bild visar infrastruktur och logiska ansvarsgränser för personuppgiftsbehandling vid synkron överföring (request-reply) från GU till en extern part:
I exemplet vill vi inte exponera källsystemet direkt mot konsumenter av någon anledning (säkerhet, svåranvänt API…). Därför ingår också en adapter på GU integrationsplattform.
Överföringen initieras av att ett behov uppstår i källsystemet, t.ex. etablering av en ny person.
TBD Data behöver berikas från GU (t.ex. studieaktivitet), men endast en delmängd av data i källsystemet får behandlas av extern part. Kriterierna för att avgöra detta är inte tillgängliga på GU (t.ex. samtycke registrerat i leverantörens system). Det faktum att leverantören känner till en identifierare (t.ex. personnummer) är tillräcklig grund för utlämnande.
Notera att Extern part har personuppgiftsansvar även för den behandling (transformering) som görs av GU (enligt PUBA).
Exempel: Parkeringsbolaget
Student vill ha en rabatt
P-bolaget är personuppgiftsansvariga (Samtycke)
P-bolaget har rätt att få ut personuppgift (studieaktivitet)
Beslutsstöd
Följande är en process som man kan använda för att bestämma vilket lösningsmönster som är tillämpbart i den aktuella situationen.
Personuppgiftsbiträdesavtal (PUBA)
Exempel
Gränsöverskridande
Flytt från en juridisk person till en annan.
Flytt från ett juridiskt område till ett annat.
Lagring/behandling hos en part som baseras i en annan juridisk zon
Två Logiska bubblor
Överföring, lagring, filtrering (behandling) kan sträcka sig över fysiska implementationer.
Den behandling som sträcker sig utanför vår infrastruktur (fysiska platsen ligger utanför juridiska personen) måste regleras.
Bild på gång!
En väldigt begriplig bild:
Typfall och scenarier
Exempel på vad vi som myndighet får respektive inte får göra och varför.
Lagra personnummer i en on-prem applikation?
Skicka personuppgifter för en student till en extern leverantör?
etc.
Länkar
Personuppgiftsbehandling hos myndigheter - Integritetsskyddsmyndigheten (imy.se)
Personuppgiftsansvariga och personuppgiftsbiträden - Integritetsskyddsmyndigheten (imy.se)
Personuppgiftsbiträdesavtal - Integritetsskyddsmyndigheten (imy.se)