Sammanfattning
Systemintegrationer är inte alltid enkla att betrakta ur ett GDPR-perspektiv. Diskussionen runt vad som är tillåtet inom GDPR hänförs väldigt ofta till systemens fysiska gränser. GDPR tar inte hänsyn till ett systems fysiska gränser utan endast om behandlingen sträcker sig till en annan juridiks person som utför behandlingar på uppdrag av personuppgiftsansvarig och i vilket land den juridiska personen (extern part) har sitt säte.
Därför behöver en överföring betraktas ur tre perspektiv för att reda ut hur överföringen skall betraktas och om det är tillåtet i enlighet med GDPR. Dessa tre perspektiv är:
Vem äger infrastrukturen som utför behandlingen
Vilken rättslig grund har behandlingen
Vem är personuppgiftsansvarig för behandlingen
Ett försök att förtydliga de olika perspektiven syns färgkoden återkommande i diagrammen nedan.
En behandling är helt skild från systemets fysiska gränser - utan behandlingen är endast kopplat till vilken part som gör behandlingen och vilket land behandlingen görs. En behandling kan alltså sträcka sig över flera system och dessutom gå över flera parter som då alla behöver teckna ett PUBA för att kunna göra behandlingen på uppdrag av GU.
Likheten i resonemanget kan göras till exempelvis lagring av filer på extern tjänst som på en begäran om utlämnade görs det direkt av leverantören på uppdrag av GU så länge den begärande parten har rättslig grund för att ta del av personuppgifterna. Dvs hur utlämnandet sker regleras tydligt av PUBA.
Genom att betrakta överföringar där GU som personuppgiftsansvarig äger en liten bit i den externa partens implementation ger en kraftigt ökad kvalitet på data som exempelvis samtycke grundar sig på samt att integrationsarkitekturen bidrar till effektivare och återanvändande av redan befintliga tjänster inom sektorn. Ett exempel är att Ladok idag redan har tjänster som publicerar studieinformation som används av flera lärosäten och som direkt skulle kunna användas för applikationer som kräver samtycke. Dvs. att använda samma Ladok LIS-tjänster till flera applikationer utan att behöva bygga nya integrationer och tjänster.
Inledning
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.
Måste skriva när dessa mönster kan användas. Det måste alltid ske en bedömning innan huruvida dessa mönster kan användas för implementering på ett effektivt sätt.
Bedöma skälet till att lägga ut behandling på extern part
För studentrabatt är det begränsad behandling med harmlösa uppgifter, medan Alumni kan vara mer omfattande och problematiskt. Den egna rättsliga grunden behöver identifieras.
Uppgifter som exempelvis om studenters psykologiska ohälsa kanske inte lämpligt.
Modeller
Begrepps- och processmodeller på denna sida finns i arkitekt-repositoryt på 2c8.
Implementationsmönster finns på Sharepoint.
Länkar
Rutiner för behandling av personuppgifter – Medarbetarportalen (gu.se)
Personuppgiftsbehandling hos myndigheter - Integritetsskyddsmyndigheten (imy.se)
Personuppgiftsansvariga och personuppgiftsbiträden - Integritetsskyddsmyndigheten (imy.se)
Personuppgiftsbiträdesavtal - Integritetsskyddsmyndigheten (imy.se)
Förordning (1993:1153) om redovisning av studier m.m. vid universitet och högskolor
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
Definitioner
Dessa begrepp förekommer ofta/alltid i diskussionen. De måste definieras och sättas i sammanhang.
Se även
Begrepp | Innebörd | Exempel |
|---|---|---|
Personuppgift | Personuppgifter är all slags information som kan knytas till en levande person. Det kan röra sig om namn, adress och personnummer. Även foton på personer klassas som personuppgifter. | |
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. Annan juridisk person. Annan juridisk zon. | |
Personuppgiftsbehandling Behandling | Varje åtgärd eller serie av åtgärder som vidtas i fråga om personuppgifter, vare sig det sker på automatisk väg eller inte, till exempel insamling, registrering, organisering, lagring, bearbetning eller ändring, återvinning, inhämtande, användning, utlämnande genom översändande, spridning eller annat tillhandahållande av uppgifter, sammanställning eller samkörning, blockering, utplåning eller förstöring. | |
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 | Det är vanligt att personuppgiftsansvariga anlitar biträden för att utföra en viss personuppgiftsbehandling för att använda biträdets specifika expertis eller erfarenhet som den personuppgiftsansvariga saknar i sin organisation. … När ett personuppgiftsbiträde behandlar personuppgifter åt den personuppgiftsansvariga, ska behandlingen regleras genom avtal (eller annan rättsakt) | Personuppgiftsbiträdesavtal - Integritetsskyddsmyndigheten (imy.se) |
General Data Protection Regulation (GDPR) Dataskyddsförordningen | ||
Lagring (behandling) | ||
Överföring (behandling) | ||
Uppgiftsminimering (princip) | Personuppgifter som behandlas ska vara adekvata, relevanta och inte för omfattande i förhållande till ändamålet. | |
Riktighet (princip) | Personuppgifter som behandlas ska vara riktiga och, om nödvändigt, uppdaterade. | |
Rättslig grund | Ett lagligt stöd i dataskyddsförordningen för att behandlingen av personuppgifter ska vara tillåten. | |
Samtycke (rättslig grund) | Med samtycke menas varje slag av frivillig, specifik, informerad och otvetydig viljeyttring, genom vilken den registrerade, antingen genom ett uttalande eller genom en entydig bekräftande handling, godtar behandling av personuppgifter som rör honom eller henne. | |
Allmänt intresse (rättslig grund) se Myndighetsutövning | ||
Myndighetsutövning och uppgifter av allmänt intresse (rättslig grund) | Alla uppgifter som riksdag eller regering gett i uppdrag åt statliga myndigheter är enligt regeringens mening av allmänt intresse. Om uppgifterna inte vore av allmänt intresse skulle myndigheterna inte ha ålagts att utföra dem. | Studieadministrativa processer OBS! Uppgifter avser i sammanhanget inte personuppgifter utan myndighetens uppdrag som en rättslig grund för behandling Se Myndighetsutövning och uppgifter av allmänt intresse - Integritetsskyddsmyndigheten (imy.se) |
Spridning |
Dessa begrepp är inte lika viktiga men ändå:
Begrepp | Innebörd | Exempel |
|---|---|---|
Dataskyddsombud | ||
Dataskyddsgruppen |
Interaktionsmönster
Push (sändare initierar)
Beskrivning
Detta mönster bygger på att uppgifter skickas till mottagaren när de etableras/uppdateras, t.ex. genom asynkron överföring (messaging eller filöverföring) eller synkront anrop till webservice. Mottagaren bearbetar (filtrerar/lagrar) uppgifterna.
Användningsområde och exempel
Tillämpbart i första hand när rättslig grund för behandling uppstår samtidigt hos GU och extern part. Kan även användas för att underhålla en cache i scenariot där Utlämnande av personuppgifter överlåts till extern part.
Exempel:
Kårens medlemsregister - Överföring av personuppgifter krävs för att avgöra om en person får vara kårmedlem eller inte. Kåren har enligt förordning 1993 rätt att göra denna behandling av samtliga studenters personuppgifter. Kan göras av extern leverantör med stöd av PUBA (leverantör-kåren). /wiki/spaces/LAD/pages/1860731013
Chalmers - Överföring av personuppgifter krävs till Chalmers interna system men för att avgöra vilka personer som är relevanta behöver filtrering göras enligt kriterier som Chalmers bestämmer. Kan göras av Chalmers med stöd av PUBA (GU-Chalmers). Integrationsarkitektur - Chalmers - Confluence (atlassian.net)
Mecenat kortproduktion - Utlämnande av personuppgifter krävs för att avgöra om en person är berättigad till rabatter baserat på studieaktivitet. Utlämnande av dessa uppgifter från GU kan ske på begäran av personen som söker rabatter. Att ansöka om rabattkort innebär samtycke till personuppgiftsbehandling vilket i sin tur ligger till grund för Utlämnande av uppgifter, som delegeras till extern part och regleras i PUBA. Detta innebär att uppgifterna kan lagras lokalt hos leverantören istället för att hämtas med synkront uppslag mot GU.
Arkitektur
Asynkron push med filter hos extern part
Följande beskriver integrationsarkitektur där filter implementeras utanför GU:s infrastruktur.
Tjänsten skickar ut ALLA uppgifter. Extern part behöver oftast göra behandling i form av någon filtrering. Denna behandling görs på uppdrag och regleras i PUBA. Anledningen till att den görs på uppdrag är att den externa aktören 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 i vissa fall. Alla uppgifter kommer att skickas och 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.
Pros | Cons |
|---|---|
Asynkron push med uppslag från cache hos extern part
Scenariot innebär Utlämnande av personuppgifter delegerat till extern part. I detta scenario används uppdateringsmeddelanden för att underhålla en lokal cache hos en extern part. Användandet av denna cache begränsas till uppslag på personnummer när en person lämnar samtycke till behandling. I denna behandling ingår att den externa parten begär ut personuppgifter från GU på uppdrag av personen i fråga.
Syftet med detta är att undvika ett synkront beroende med uppslag mot GU. Samma data är tillgänglig för leverantören men i form av en enklare teknisk lösning.
Pros | Cons |
|---|---|
Pull (mottagare initierar)
Beskrivning
Pull / Request-Reply / on demand. En extern part frågar GU. GU har kontroll över utlämnandet.
Användningsområde och exempel
Detta är lämpligt att använda när rättslig grund för behandling hos extern part uppstår i efterhand t.ex. samtycke vid en senare tidpunkt än då studenten etableras, ändrar studieaktivitet etc. om inte en lösning med lokal cache enligt ovan är önskvärd.
Exempel:
“Parkeringsbolaget” - Student vill ha en rabatt, P-bolaget är personuppgiftsansvariga (Samtycke). P-bolaget har rätt att få ut personuppgift (studieaktivitet) i efterhand.
Arkitektur
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 detta fall regleras förhållandet mellan GU och extern part genom ett Tjänsteavtal t.ex. att extern part har rätt att begära ut information om student baserat på personnummer.
Pros | Cons |
|---|---|
Beslutsstöd
Rättsliga aspekter
Det måste finnas en rättslig grund för behandling av personuppgifter. För GU är den rättsliga grunden oftast att behandling krävs för myndighetsutövning (den uppgift av allmänt intresse som GU utför).
Push-överföring av personuppgifter till en extern aktör (t.ex. en systemleverantör) innebär inte automatiskt att denna aktör blir personuppgiftsansvarig i rättslig mening. Behandling (t.ex. filtrering) kan göras av leverantören på GU:s uppdrag i egenskap av personuppgiftsbiträde, om denna regleras i PUBA.
Det är i detta fall fortfarande GU som ansvarar för behandlingen och den görs med rättslig grund som gäller för GU.
Juridiska aspekter hanteras av GU:s förvaltningsjurister.
Datasäkerhetsaspekter
En personuppgiftsbehandling kan vara olämplig ur ett datasäkerhetsperspektiv även om det rent formellt finns en rättslig grund. Att sätta upp en integration kräver godtagbar säkerhetsnivå för autentisering, transport, spårbarhet etc. Syftet är att hindra “läckage” på vägen eller inom leverantörens system.
För detta behövs en riskanalys ur tekniskt perspektiv där man även väger in leverantörens förmåga att upprätthålla och följa avtal. Denna kompletterar befintlig risk- och sårbarhetsanalys för lösningen.
Exempel: Problematik t.ex. kring tredjeland (USA-bolag) där inhemsk lagstiftning kan trumfa ingångna avtal. Därmed behöver andra tekniska och organisatoriska skyddsåtgärder vara på plats. T.ex. övervakning av fjärråtkomst vid teknisk support.
Exempel: Överföring av personuppgifter till en kommersiell aktör på villkor att denne bara ska behandla uppgifter i sitt system för personer som lämnat samtycke till detta. Denna filtrering regleras i PUBA och görs av den externa aktören på uppdrag av GU. Rent juridiskt finns inga hinder för detta, men det kan vara olämpligt av andra skäl t.ex. att man bedömer att det finns ett starkt incitament hos leverantören för att kringgå avtalet.
Datasäkerhetsaspekter hanteras av informationssäkerhetssamordnare, IT-arkitekter samt vid behov GU:s säkerhetschef.
Beslutsprocess
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.
Det är lätt att man blandar ihop rättsliga och säkerhetsmässiga aspekter vid beslut om lösningsmönster för integration. Processen behöver ev förtydligas avseende juridisk/teknisk riskanalys enligt ovan och vad som ligger till grund för vilket beslut.
Personuppgiftsbiträdesavtal (PUBA)
Exempel
Dokument och mallar – Medarbetarportalen (gu.se)
Vad ska ett personuppgiftsbiträdesavtal innehålla?
(text från IMY Personuppgiftsbiträdesavtal - Integritetsskyddsmyndigheten (imy.se))
Enligt artikel 28.3 ska avtalet innehålla följande information om behandlingen:
föremålet för behandlingen och behandlingens varaktighet
behandlingens art och ändamål
typer av personuppgifter och kategorier av registrerade
den personuppgiftsansvarigas rättigheter och skyldigheter.
Det är väldigt viktigt att den personuppgiftsansvariga tydligt klargör vilka personuppgiftsbehandlingar det är man vill lägga över på ett personuppgiftsbiträde.
Juridiska hinder
Man måste givetvis bedöma redlighet och lämplighet hos den aktören som skall utföra behandlingen innan beslut kan tas:
Bedömning måste göras som alltid enligt
OSL
GDPR
Vilka är minimikraven för ett avtal?
I artikel 28.3 anges dessa minimikrav för vad ett personuppgiftsbiträdesavtal ska innehålla:
att behandling endast får ske enligt dokumenterade instruktioner från den personuppgiftsansvariga
försäkran om konfidentialitet eller lagstadgad tystnadsplikt
lämpliga säkerhetsåtgärder
villkor för anlitande av underbiträden
skyldighet att vidta åtgärder för att uppfylla de registrerades rättigheter
bistå den personuppgiftsansvariga i fråga om dennes skyldigheter enligt artikel 32-36
hur personuppgifter ska hanteras när avtalet upphör
skyldighet att gå med på och bistå vid granskning och inspektioner.
Personuppgiftsansvarig och personuppgiftsbiträde kan alltid komplettera minimikraven med ytterligare avtalsvillkor. Minimikraven beskrivs utförligare nedan.
Typfall och scenarier
Under arbete. Komplettera med 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.
Exempel på scenarier där ovanstående resonemang tillämpas: