Formålet med denne retningslinje er at sikre:
- At SDU har en systematisk måde at vurdere it-systemer på ved indkøb og udvikling af nye it-systemer.
- At SDU har vurderet risikoen for SDU og risikoen for de personer, hvis oplysninger, der evt. behandles systemerne forud for idriftsættelse/ibrugtagen af nye it-systemer.
Baggrund
Ved anskaffelse og udvikling af nye it-systemer er der krav om, at systemet har passende organisatoriske og tekniske sikkerhedsforanstaltninger. Der er ligeledes krav om, at der kan påvises ansvarlighed i forhold til behandling af personoplysninger. I praksis betyder det, at der er behov for at udarbejde flere forskellige typer risikovurderinger, for at det kan påvises, at kravene i GDPR er opfyldt.
Overordnet skal retningslinjen sikre, at SDU dokumenterer overvejelserne for disse 4 krav:
Hurtig navigation:
Ad. 2b Større it-anskaffelser underlagt udbud og/eller Digitaliseringsporteføljen
SDU’s tilgang til risikovurderinger
SDU har en risikobasseret tilgang til vurdering af it-systemer. Systemer der er kritiske for opretholdelse af SDU’s kerneopgaver eller som understøtter andre systemer, der er kritiske for SDU skal have en omfattende risikovurdering, hvor der benyttes en risikomatrix (sandsynlighed x konsekvens) efter ISO 27005 principperne, svarende til type 2 i baggrundsafsnittet. Systemer, der indeholder personoplysninger, skal have passende dokumentation for, at GDPR er opfyldt. Kategorier af personoplysninger samt omfanget og omstændighederne af behandlingen af personoplysninger har betydning for, hvor meget dokumentation, der skal laves. Det betyder, at mindre omfattende behandling kan nøjes med en mindre vurdering.
Er behandlingen mere omfattende, skal er laves en risikovurdering relateret til behandling af personoplysninger (Privacy Impact Assessment), svarende til type 3 i baggrundsafsnittet hvis:
- Der sker omfattende behandling af personoplysninger (fx behandling af alle danskeres nummerplader)
- Der behandles følsomme eller fortrolige personoplysninger
- Der behandles oplysninger om særligt sårbare grupper (fx børn eller psykisk syge)
Hvis det viser sig, at der er ”høj” risiko for de personer, hvis oplysninger, der behandles i systemet, er der krav om, at der udarbejdes en konsekvensanalyse (DPIA = Data Protection Impact Assessment). Der kan være iboende høj risiko for de registrerede, hvis der anvendes ny teknologi som AI til behandling af personoplysninger, eller hvis der sker omfattende profilering eller træffes automatiske afgørelser i systemet. DPIA risikovurderingen beskrives i en særskilt retningslinje og behandles ikke yderligere i denne retningslinje.
Anvendelsesområde
Gælder for alle ansatte på SDU. Overordnet opdeles it-systemerne i følgende 3 kategorier:
1) Egenudviklede systemer (ved mindre tilpasninger og add-on på eksisterende systemer kan man nøjes med at opdatere den eksisterende risikovurdering).2) Centrale systemer, der indkøbes og licensstyres af SDU IT herunder systemer, hvor der sker interaktion med studerende.
a. Mindre it-anskaffelser med begrænset anvendelse på SDU (fx SPSS, transkriberingsværktøj)
b. Større it-anskaffelser, hvor der er krav om udbud og/eller anskaffelsen sker via Digitaliseringsporteføljen (fx e-learningssystem, økonomisystem, studieadministrativt system)3) Lokale systemer der anvendes til afgrænsede forskningsprojekter eller andre lokale formål, der ikke er rettet mod studerende.
Retningslinjen omfatter ikke governance i forhold til budgetdisponering.
Ansvar
Som udgangspunkt er det systemejeren, der har det samlede ansvar for it-anskaffelsen. Systemejeren er dermed ansvarlig for, de nødvendige databeskyttelsesrisikovurderinger bliver lavet og dokumenteret
Systemejerskabet placeres, hvor det organisatorisk giver bedst mening. Alle systemer skal have en systemejer. Systemejerskabet på mindre it-anskaffelser vil som udgangspunkt være placeret i SDU IT, hvis systemet stilles til rådighed for et større antal mennesker på SDU og SDU IT styrer licenserne.
Systemejerskabet på mindre it-anskaffelser (herunder freeware), der kun finder begrænset anvendelse fx på ét institut, men hvor flere ansatte arbejder i systemet, eller der sker interaktion med studerende, vil typisk blive placeret på det institut eller fællesområde, der anmoder om anskaffelsen af systemet.
Ved lokale systemer omfattet af kategori 3 er det er den enkelte forsker eller dennes institutledelse, der er systemejer og dermed ansvarlig for, at der er lavet de nødvendige databeskyttelsesrisikovurderinger både i relation til SDU og evt. personer, hvis data, der behandles i systemet.
SDU IT, SDU RIO og SDU Digital har en opgave med at understøtte processen med at anskaffe it-systemer herunder udarbejdelsen af relevante risikovurderinger.
Anskaffelsesvurdering understøttes jf. skemaet:
Det fællesområde, fakultet eller institut, der ønsker anskaffelse af et it-system, har selv ansvar for at tilvejebringe de informationer, der skal til for at SDU IT, SDU RIO og SDU Digital kan understøtte selve risikovurderingerne.
SDU RIO står for indgåelse/godkendelse af alle databehandleraftaler. I relation til det dokumenterer de vurdering af leverandør og GDPR-screening.
SDU IT dokumenterer den indledende screening af it-sikkerheden.
SDU Digital dokumenterer (evt. i samarbejde med en leverandør) efterlevelse af databeskyttelse gennem design og standardindstillinger.
SDU Digital Compliance understøtter systemejeren med dokumentation af risikovurderinger i relation til SDU og de registrerede (PIA) og vurderer evt. behov for konsekvensanalyse (DPIA).
Samlet oversigt over risikovurderinger relateret til anskaffelsen:
Fremgangsmåde
Ad. 1 Egen udviklede systemer
Når SDU udvikler egne systemer, kører projektet som udgangspunkt via SDU’s Digitaliseringsportefølge. Mindre udviklingsopgaver vil som regel være i tilknytning til et allerede etableret system, hvorfor det kun vil være nødvendigt at opdatere den eksisterende risikovurdering, såfremt det vurderes relevant.
SDU projektmodel indeholder de fleste af de informationer, der er behov for. Anmoder skal derudover oplyse:
Om det forventede antal registrede i systemet.
Om der benyttes ny teknologi.
Om der laves profilering eller automatiske afgørelser i systemet.
Hvem behandles der personoplysninger om i systemet (medarbejdere, studerende, deltagere i forskningsprojekter)
Hvilke personoplysninger der forventes behandlet i systemet (almindelige, fortrolige, følsomme personoplysninger). Se typer af personoplysninger her.
Hvilken dataklassifikation det forventes systemet skal kunne indeholde. Se typer af dataklassifikationer her.
Det anbefales, at projektmodelskabelonen opdateres med de nævnte oplysninger eller der laves anden relevant tjekliste.
SDU Digital Design indtænker og dokumenterer databeskyttelse gennem design og standardindstillinger:
Er standardinstillingerne lavet, så den registrede nyde størst grad af beskyttelse.
- Er der relevant dataminimering (indsaml kun nødvendige oplysninger)
- Er behandlingen af personoplysninger proportional
- Er det kun nødvendige personoplysninger, der er synlige i brugergrænsefladen (tilpasset visning/adgang til individuelle brugere/brugergrupper)
- Er der relevant adgangsstyring/brugerstyring
- Er der kryptering i lagring og transport
- Er det muligt at anonymisere, pseudonymisere eller separere oplysninger
- Er det muligt at generalisere fx aggregere data o Informer – kan behandling laves synlig for den registrerede (fx privacy dashboard)
- Kontroller – er der mulighed for den registrerede for at kontrollere og evt. berige data.
- Er det muligt at søge og udtrække oplysninger af systemet fx i forbindelse med indsigtsretten
- Er der indbygget regler for datas udløbsdato (Information Lifecycle Management)
- Er der mulighed for at indbygge privatlivsfremmende teknologier (fx data loss prevention, identity and access governance)
Relevante arkitekturudvalg herunder sikkerhedsarkitektur:
- Fx om OWASP-principperne er blevet fulgt (OWASP Top Ten, Development Guide, Code Review Guide)
Relevante standarder:
- Fx ISO 25010:2011 pkt. 4.2 Product quality model
- DS/EN 17529:2022 Data protection and privacy by design and by default
Dokumentationen koordineres af projektlederen, men udføres i praksis af den tilknyttede løsnings-arkitekt i samarbejde med udviklerne.
SDU Digital Compliance koordinerer og understøtter dokumentationen af risikovurderingen set i forhold til SDU og de registrerede jf. skabelonerne i risikovurderingskonceptet, der tager udgangspunkt i ISO 27005 og ISO 29134.
Projektlederen initierer og koordinerer den samlede dokumentation og sikrer, at risikovurderingerne godkendes af styregruppen/systemejer. Krav om dokumentation for diverse risikovurderinger indskrives i projektledernes tjekliste.
Ad. 2a Mindre it-anskaffelser
Anmodning om anskaffelse af et mindre it-system (kategori 2a) oprettes fremadrettet via formular til Servicedesken.
- Formål med anskaffelse af systemet (hvad skal det bruges til?)
- Om der skal behandles personoplysninger i systemet
o Hvis ja, hvilken type (almindelige, fortrolige, følsomme)
- Hvem behandles der personoplysninger om i systemet (medarbejdere, studerende, deltagere i forskningsprojekter)
- Hvilken dataklassifikation det forventes systemet skal kunne indeholde
- Det forventede antal brugere af systemet
- Hvilken leder der har godkendt anmodningen
- Link til systemets hjemmeside
- At SDU ikke har et lignende allerede godkendt system.
- Derefter laves en indledende screening af it-systemet via complianceværktøj i O365.
- Herefter dokumenteres:
o hvordan data lagres i systemet (hos leverandør (SaaS), lokalt på PC eller anden SDU leveret tjeneste som OneDrive)
o hvordan der kan laves adgangsstyring af systemet (fx AD-integration, WAYF eller brugernavn og adgangskode)
o Hvordan man kan oprette og nedlægge brugere
o Om der er passende kryptering, log og backup (fx bør der være fuld log inkl. selog, hvis der behandles følsomme og fortrolige personoplysninger)
o Om systemet kan implementeres uden der gives disproportional adgang til andre af SDU’s data fx mail og kalender.
o SecOps umiddelbare vurdering af om systemet udgør en fare for SDU’s øvrige systemlandskab.
- Om der gøres brug af problematiske (under)databehandlere.
- Om der er risiko for utilsigtede eller tilsigtede tredjelandsoverførelser
o Hvis ja, vurderes det evt. i samarbejde med SDU Digital Compliance, om der kan laves relevante supplerende foranstaltninger.
- Om leverandøren har et problematisk brug af data til egne formål (formål der går udover licens-kontrol, kapacitets styring og de gængse cookie-oplysninger)
- Om der generelt er tiltro til leverandøren (fx certificeringer, relevante referencer til andre kunder, tilgængelig support funktion, løbende sikkerhedsopdateringer)
- Vurdering om der er krav om indgåelse af databehandleraftale
o Hvis ja, om leverandøren vil indgå SDU’s databehandleraftale eller om leverandørens standard databehandleraftale kan accepteres.
- Om der er behov for en udvidet risikovurdering i relation til SDU og de registrerede.
Både SDU IT og SDU RIO kan afvise et system. På baggrund af en samlet vurdering fra SDU IT og SDU RIO gives følgende godkendelse:
1) Godkendes (ubetinget godkendelse – systemet kan implementeres uden videre tiltag)
2) Betinget godkendelse (krav om foranstaltninger fx organisatoriske i form af instruks for brug af systemet fx hvis det ikke kan bruges til personoplysninger, eller tekniske foranstaltninger, som der skal tages højde for ved implementeringen).
3) Afslag på anmodning (at systemet ikke kan godkendes pga. sikkerhedsmæssige, lovmæssige eller økonomiske årsager).
Den digitale organisation vedligeholder og udstiller en liste med alle godkendte og afviste systemer. Listen skal indeholde oplysninger om, hvad systemet er godkendt til i forhold til klassifikation af data og personoplysninger.
Ad. 2b Større it-anskaffelser underlagt udbud og/eller Digitaliseringsporteføljen
SDU projektmodel indeholder de fleste af de informationer, der er behov for. Anmoder skal derudover oplyse:
Om det forventede antal registrede i systemet.
Om der benyttes ny teknologi.
Om der laves profilering eller automatiske afgørelser i systemet.
Hvem behandles der personoplysninger om i systemet (medarbejdere, studerende, deltagere i forskningsprojekter)
Hvilke personoplysninger der forventes behandlet i systemet (almindelige, fortrolige, følsomme personoplysninger). Se typer af personoplysninger her.
Hvilken dataklassifikation det forventes systemet skal kunne indeholde. Se typer af dataklassifikationer her.
Det anbefales, at projektmodelskabelonen opdateres med de nævnte oplysninger eller der laves anden relevant tjekliste.
Forud for indkøb:
Projektlederen kontakter Indkøb og Udbud i god tid forud for indkøbet med henblik på planlægning af en udbudsprocessen og sikrer i samarbejde med Indkøb og Udbud relevant inddragelse af:
- SDU Digital Design og SDU IT inddrages i udarbejdelsen af krav til systemet herunder funktionalitet, arkitektur, drift og vedligeholdelse.
- SDU Digital Compliance inddrages i udarbejdelse af krav til databeskyttelse og informationssikkerhed herunder databeskyttelse gennem design og standardindstillinger.
- SDU RIO inddrages i forhold til krav relateret til databehandleraftalen og generelle krav til leverandøren.
Der bør være en relevant dialog vedrørende mindstekrav, så projektet ikke stilles i en situation, hvor det vindende udbud ikke kan opfylde grundlæggende funktioner og lovkrav.
Forud for idriftsættelsen:
Projektlederen sikrer koordinering af følgende dokumentation bliver udarbejdet:
SDU Digital Design (løsnings-arkitekt og leverandør).
SDU Digital Compliance koordinerer mellem forretningen (systemejers afdeling), leverandør (via projektleder), SDU IT, andre i SDU Digital og SDU RIO.
SDU RIO ved indgåelse af databehandleraftalen.
Ad. 3 Lokale systemer
Forskerservere der driftes af SDU IT underlægges en forvaltningsaftale, der beskriver ansvarsfordelingen mellem SDU IT og den enkelte forsker.
SDU RIO understøtter og vejleder forskere i relation til GDPR-spørgsmål.
SDU Digital Compliance stiller skabeloner til rådighed til diverse risikovurderinger i relation til SDU og de registrerede, og understøtter gerne processen, hvis spørgsmål ikke kan afklares via den lokale informationssikkerheds- og GDPR koordinator.
Ved anskaffelse og brug af mindre systemer herunder freeware, som ikke kører gennem central godkendelse og indkøb (ad. 2a) er det den enkelte VIP/TAP, der selv ansvarlig for, at systemet kan anvendes forsvarligt til den type data, som der behandles i systemet. Det gælder særligt, hvis der behandles fortrolige oplysninger i systemet eller personoplysninger.
Såfremt der behandles personoplysninger udover oplysninger, der bruges til brugeradministration (navn og arbejdsmail), skal der indgås en databehandleraftale. Det er fortsat SDU RIO der indgår/godkender eventuelle databehandleraftaler.
Bemærk venligst, at systemer, der anvendes i relation til studerende, altid skal centralt godkendes (ad. 2a), da SDU altid vil være dataansvarlig, når der kommunikeres med eller behandles oplysninger om studerende.