Hensikt og omfang
Hensikt med rutinen er å gi en oversikt over de forskjellige risikovurderingene som gjøres i et prosjekt, og når og hvordan de utføres. Hensikten med risikostyring er å identifisere, vurdere og styre risiko, og som et resultat av det, forbedre prosjektets sjanser til suksess.
Dette dokumentet er basert på regionale prosedyrer «Risikostyring i Helse Midt-Norge - Rammeverk (RIS)» og «Risikostyring i Helse Midt-Norge - Prosedyre (RIS)», Finansiell usikkerhetsstyring av investeringer i Helse Midt-Norge (Ikke tilgjengelig), Risikostyring av informasjonssikkerhet og Fasilitering av Personverkonsekvensvurdering (DPIA).
Rutinens bruksområde er
fire-delt, og disse fire gjennomføres ikke samtidig eller for alle prosjekt:
· Risikostyring av prosjekt og release
· Finansiell usikkerhetsstyring av investeringer i Helse Midt-Norge
· Risikoanalyse av informasjonssikkerhet (ROS-analyse) i IKT-løsninger
· Personvern i IKT-løsninger (DPIA)
· Risikovurderinger ved Kunstig Intelligens
Ansvar
· Prosjekt-/releaseleder er ansvarlig for risikostyring av prosjektet/releasen ved aktivt å benytte risikostyring for å planlegge prosjektets eller releasens aktiviteter underveis, samt iverksette tiltak for å få kontroll med risiko.
· For store prosjekter kan prosjekt/release-leder delegere ansvar for oppfølging av risiko til en egen rolle for dette (risikoansvarlig).
Definisjoner
· Risiko:
· ISO 31000:2018 definerer risiko som:
o «virkning av usikkerhet knyttet til et mål», der «en ‘virkning’ er et avvik fra det forventede, positivt og/eller negativt». Risiko uttrykkes ofte i form av risikokilder, potensielle hendelser, sannsynligheten for at de skal forekomme, og deres mulige konsekvenser.
- PRINCE2 definerer risiko som:
- en potensiell hendelse, eller et sett av hendelser som, skulle de inntreffe, vil ha en innvirkning på hvorvidt målene kan nås. En risiko (usikkerhet) måles av en kombinasjon av sannsynligheten for at en trussel eller mulighet kan inntreffe og hvor stor virkningen blir på målene.
- Merk: I den norske oversettelsen av PRINCE2-metodikk benyttes begrepet «usikkerhet», i stedet for «risiko», for å fremheve at både trusler og muligheter skal ivaretas ved risikostyringen. I den originale engelske versjonen benyttes begrepet "risk", dette er i overensstemmelse med ISOs definisjon. I HMN er det valgfritt å bruke "risiko" eller "usikkerhet".
· Trussel: usikre hendelser som kan ha en negativ innvirkning på målene
· Mulighet: usikre hendelser som kan ha en positiv innvirkning på målene
Arbeidsbeskrivelse
Risikostyring av prosjekt og release
Hva
Dette omfatter risikoer for trusler mot å nå prosjektmål, eller å ikke oppnå gevinster. Risikoer kan også være positive (muligheter). Risikovurderinger brukes aktivt for å planlegge tiltak underveis i prosjektet eller releasen for å redusere risiko. Det skal opprettes et risikoregister.
Merk: rutinen tjener som standard risikostrategi for prosjekter i Helse Midt-Norge. Et prosjekt eller en release kan velge å avvike fra standard risikostrategi, og heller formulere sin egen risikostrategi spesielt tilpasset prosjektet eller releasen. Avvik fra standard risikostrategi skal imidlertid grunngis og berettiges i prosjektets eller releasens prosjektplan/ releaseplan, og legges frem for styringsgruppen for godkjenning.
Når og for hvilke prosjekter/releaser
Gjennomføres for alle prosjekter, og oppdateres kontinuerlig gjennom hele prosjektet:
· Risikoregisteret opprettes som en del av prosjektplanleggingen i planleggingsfasen Prosjekt, Planlegge).
· Risikoregisteret skal revurderes minimum ved den månedlige statusrapporteringen (se Prosjekt og release, Rapportering), i forbindelse med gevinstrealisering (se Prosjekt, gevinstrealisering), og i forbindelse med faseoverganger Prosjekt, Lede en faseovergang).
Gjennomføres før alle releaser.
For prosjekter: som risikoregister brukes usikkerhetsregisteret på prosjektets Sharepoint-side på HMN Prosjektweb365.
For releaser brukes excel-malen vedlagt.
Som alternativt risikoregister i prosjektet kan vedlagte excel-mal benyttes (se vedlegg), denne skal i tilfelle legges inn på prosjektets prosjektweb, og linkes til forsiden slik at den er lett synlig.
Figuren nedenfor viser gangen i opprettelse av risikoregisteret:
1. Identifisere (potensielle hendelser)
Merk at risikoer er hendelser som kan opptre i framtiden. Risikoer som allerede har inntruffet omfattes ikke av analysen. Kilder til å identifisere risikoer kan være: lignende, tidligere prosjekter og programmer, generisk liste for risiko (se vedlegg), idedugnad. Tenk både trusler mot at prosjektet når mål (økonomisk, leveringsdato, kvalitet) og trusler mot at gevinster nåes. Hvilke barrierer kan hindre at planlagte gevinster oppnås? Vurder modenhet, kapasitet og kompetanse i organisasjonen som skal ta i bruk noe nytt.
For å sikre en god beskrivelse av risikoen skal følgende kartlegges:
- Årsak: Hvorfor oppstår risikoen? Hva er kilden til risikoen?
- Virkning: Hvilke resultater medfører risikoen dersom den inntreffer?
Det oppfordres til å se etter positive risikoer (muligheter), og ikke bare negative (trusler).
2. Vurdere (sannsynlighet og konsekvens)
For hver hendelse identifiseres sannsynlighet på en skala 1-5, og konsekvens på en skala 1-5. Nivå for sannsynlighet og konsekvens av hendelser skal angis i tråd med kriteriene beskrevet i Dokument «Risikostyring i Helse Midt-Norge - Prosedyre (RIS)», ID 1435 - EQS (helse-midt.no).
Risikoene plasseres i et rutenett med skalaer for sannsynlighet og konsekvens. Denne matrisen gir en god oversikt over risikoprofil for prosjektet, er et godt hjelpemiddel for vurdering av risikoer og benyttes bl.a. i planlegging av tiltak.
|
Sannsynlighet |
Ubetydelig (1) |
Liten (2) |
Moderat (3) |
Alvorlig (4) |
Kritisk (5) |
|
|
Svært høy (5) |
|
|
|
|
|
|
|
Høy (4) |
|
|
|
|
|
|
|
Middels (3) |
|
|
|
|
|
|
|
Lav (2) |
|
|
|
|
|
|
|
Svært lav (1) |
|
|
|
|
|
|
|
Konsekvens |
|
|||||
Dersom det er identifiserte positive risikoer (muligheter) i prosjektet, skal disse presenteres i en separat mulighetsmatrise.
På Prosjektweb365 vil mulighetsmatrisen automatisk bli generert dersom det er opprettet usikkerheter av type «mulighet».
3. Planlegge (tiltak)
Det skal listes mulige tiltak for alle registrerte risikoer. Dette for at man skal kunne vurdere hvilke tiltak som skal iverksettes. Tiltakene dreier seg vanligvis om (se komplett tabell over mulige tiltak lenger ned):
- Redusere sannsynlighet for at hendelsen inntreffer
- Redusere konsekvens av hendelsen, dvs. lage en "Plan B"
- Undersøke mer omkring usikkerheten, f.eks. ved å tidlig gjennomføre innledende testaktiviteter, eller lage en "Proof-of-Concept".
Generelt bør man som et absolutt minimum gjennomføre tiltak for alle risikoer som havner i oransj eller rød sone i risikomatrisen. Ved risikoer i rød sone uten muligheter for tiltak må styringsgruppen vurdere om dette har konsekvenser for videre gjennomføring av prosjektet.
Det er viktig å balansere kostnader (både kvalitative og økonomiske) ved implementering av tiltak opp mot konsekvensen dersom risikoen slår til. Dette brukes som et grunnlag for å prioritere hvilke tiltak som skal foretas.
Dersom det er opprettet et risikobudsjett for prosjektet, som regel registrert i posten uforutsette kostnader, benyttes disse midlene for gjennomføring av eventuelle tiltak.
4. Iverksette (tiltak)
Målsettingen er å sikre at planlagte tiltak faktisk utføres, overvåke effekter av tiltak og sørge for korrigering dersom ønskede effekter uteblir.
· Prosjekt/release-leder er ansvarlig for overvåking og oppfølging av tiltak.
· Det er viktig å vite hvor nærliggende en risiko er, dvs. hvor nært opptil dette øyeblikk risikohendelsen kan forventes å oppstå. Dette fordi man kan planlegge når tiltak bør iverksettes.
· Alle tiltak skal ha en tiltaksansvarlig som skal sørge for gjennomføring av tiltak.
o Dersom tiltaksansvarlig er noen andre enn Prosjektleder, skal navn på personen angis i risikoregisteret.
o Angi ansvarlig person enten i beskrivelsen av hvert tiltak sammen med frist, eller angi ansvarlig i separat kolonne «Ansvarlig» dersom samme person har ansvaret for alle tiltakene for en og samme hendelse.
· Dersom en hendelse ikke lengre er aktuell skal risikoen ikke lengre inngå i risikomatrisen.
o På Prosjektweb365 endres status på risikoen til «ikke lengre aktuell» i usikkerhetsregisteret. Da blir den automatisk borte fra risikomatrisen, men ligger fortsatt liggende i listen over identifiserte risikoer.
o I excel gjøres dette manuelt, det vil si endre status til Ikke lengre aktuell, og fjerne risikoen fra matrisen.
5. Kommunisere
Denne aktiviteten utføres kontinuerlig og skal sørge for informasjon om relevante muligheter og trusler, både internt i prosjektet og til alle eksterne interessenter.
· Risiko som påvirker det enkelte prosjektet mht. tid, kostnad, kvalitet/omfang, eller gevinst skal formidles til styringsgruppen
· De viktigste verktøyene for kommunikasjon av risiko er Prosjektstatus på Prosjektweb, saksunderlag til styringsgruppemøter, og oppdatering av prosjektbegrunnelse til hver faseovergang.
Finansiell usikkerhetsstyring av investeringer i Helse Midt-Norge
Hva
Dette er økonomisk usikkerhet ifm med investeringer, samt styringen og disponering av tilhørende prosjektreserver.
Usikkerhet i denne sammenhengen er differansen mellom den informasjonen som er nødvendig for å ta en sikker beslutning og den informasjonen som er tilgjengelig på tidspunktet for beslutningen. Det skilles i analysen mellom estimatusikkerhet og hendelsesusikkerhet.
Når og for hvilke prosjekter/releaser
I rutine Finansiell usikkerhetsstyring av investeringer i Helse Midt-Norge (Ikke tilgjengelig) er omfanget for finansiell usikkerhetsstyring delt opp i tre nivåer:
a) Investeringer under 10 MNOK
b) Investeringer fra 10 til 50 MNOK
c) Investeringer over 50 MNOK
Nivå c) er i praksis det nivået der IKT-prosjekter må gjøre en ytterligere analyse utover den vanlige risikostyringen i et prosjekt. Plan for håndtering av finansiell usikkerhet etableres i oppstart av investeringsprosjektet, og vedlikeholdes gjennom alle prosjektfaser.
Hvordan
Se rutine slik den er beskrevet i gjeldende regionalt dokument, se Finansiell usikkerhetsstyring av investeringer i Helse Midt-Norge (Ikke tilgjengelig).
Hvordan for de tre nivåene (a, b og c) beskrives i kapittel 5.3:
· For IKT-prosjekter under 50 mill. i Helse Midt-Norge skal det alltid benyttes kvalitativ analyse som beskrevet i Risikostyring av prosjekt og release. Ettersom en kvalitativ analyse er mer omfattende enn en SWOT-analyse er det dermed ikke krav om SWOT-analyse i tillegg, og det skilles derfor ikke på nivå a) og b) for IKT-prosjekter.
o Hendelsesusikkerheter med mulige økonomiske konsekvenser inkluderes i den allerede opprettede risikomatrisen i prosjektet. Se kapittel 5.3.2 i Finansiell usikkerhetsstyring av investeringer i Helse Midt-Norge (Ikke tilgjengelig) for ytterligere veiledning.
· For store prosjekter over 50 mill., nivå c), skal det gjennomføres full finansiell analyse, både kvalitativ og kvantitativ analyse. Se kap. 5.3.3. () i Finansiell usikkerhetsstyring av investeringer i Helse Midt-Norge (Ikke tilgjengelig).
o Den kvalitative delen av den finansielle usikkerhetsanalysen gjennomføres på samme måte som IKT-prosjekter under 50 millioner, med etablering av mulige hendelser i risikomatrisen.
o Som grunnlag for den kvantitative finansielle analysen skal det på forhånd ha blitt gjennomført tre-punkts-estimering i henhold til estimatmodell i Prosjekt, prosjektbudsjett.
o Det anbefales å trekke inn en ekstern part for å gjennomføre den kvantitative analysen.
Risikoanalyse av informasjonssikkerhet (ROS-analyse) i IKT-løsninger
Hva
Dette er en risiko- og sårbarhetsanalyse for å systematisk håndtere informasjonssikkerhetsrisiko i en prosjektleveranse.
Når
Risikovurderingsrapporten av informasjonssikkerhet ferdigstilles som regel 1 gang, i god tid forut for produksjonssetting av ny (versjon av) løsning, men sikkerhetsvurderinger bør påstartes så tidlig som mulig i prosjektet og fortsette gjennom alle faser.
For eksempel vil en tjeneste som eksponeres til internett, behandling av helseopplysninger i en skytjeneste eller at man tar i bruk ny teknologi medføre økt angrepsflate, økt trussel og dermed høyere risiko som må adresseres i prosjektleveransen, og gir føringer for hvilke sikkerhetskrav som er relevante å stille.
For hvilke prosjekter/releaser skal ROS-analyse gjennomføres?
· Alle nye anskaffelser og utviklingsprosjekt som innebærer nye IKT-løsninger
· Større endringer på løsninger som påvirker tidligere gjennomførte ROS-vurderinger
· IKT-infrastruktur-prosjekter
· Ved betydelig avvik fra Hemit Sikkerhetsplan og/eller HMN sikkerhetsprinsipper jf Dokument «Sikkerhetsprinsipper- og krav til IKT-infrastruktur og -tjenester », ID 1390 - EQS
Kravet til at en ROS-analyse skal gjennomføres er skjerpende dersom tjenesten eksponeres mot internett, for sky, har KI (kunstig intelligens) i hele eller deler av løsningen, eller man tar i bruk annen ny teknologi.
Hvordan
ROS-analysen skal gjennomføres etter rutine: Risikostyring av informasjonssikkerhet, og de maler for risikovurderingsskjema og risikovurderingsrapport som ligger linket skal benyttes.
1) Konseptfase:
o Vurder behovet for informasjonssikkerhet: er noen av de identifiserte behovene til konfidensialitet, integritet, tilgjengelighet, eller regelverk slik at dette kan påvirke konseptvalget?
o Ta eventuelt høyde for ROS som aktivitet i prosjektbudsjett.
2) Planleggingsfase:
o Det anbefales at risikoskjemaet for informasjonssikkerhet etableres, se mal for det i Risikostyring av informasjonssikkerhet, med påbegynt utfylling av tenkte sårbarheter.
o Det anbefales at nødvendige ressurser til ROS-organisasjonen avklares, inkludert at risikoeier identifiseres.
o Gjennomfør fase 1 av risikovurdering for det valgte konseptet se Veileder for gjennomføring av risikovurdering av informasjonssikkerhet (Ikke tilgjengelig), så langt det er mulig.
3) Gjennomføringsfase:
o Før utlysing av anbud: sikre krav til informasjonssikkerhet i løsningen, se Prosjektmetodikk, kravspesifisering.
o Gjennomføring av fase 2 - fase 4 i Risikostyring av informasjonssikkerhet, dette kan være en iterativ prosess som gjentas flere ganger gjennom prosjektet.
§ Ferdigstille risikovurderingsrapporten (fase 5).
o Behandling av ROS-vurderinger:
§ Alle ROS’er på systemer som skal inn i Helse Midt-Norge’s infrastruktur skal presenteres i FORD (Forum for ROS og DPIA) og områdestyret, uavhengig av risikonivå, selv om kun ett foretak skal bruke systemet.
§ For IKT-løsninger som skal opp i sky skal risikovurderingen opp til behandling i FORD og aktuelt områdestyre, selv om den berører kun ett foretak.
§ Dersom løsningen inneholder kunstig intelligens, avklar med informasjonssikkerhetsleder om ROS bør behandles i FORD og områdestyret.
§ Saker som meldes til FORD skal være forberedt med saksunderlag (Risikovurderingsrapporten). FORD sitt mandat er å kvalitetsikre risikobilde og de identifiserte tiltak, samt gi faglige råd til beslutningstakere i linjeorganisasjonen.
o Godkjenning.
ROS godkjennes av områdestyret, eventuelt Digitaliseringsstyret om risikoen er
veldig høy. Se Risikostyring av informasjonssikkerhet og Dokument
«NO-4 Organisering av informasjonssikkerhets og personvernarbeidet i Helse
Midt-Norge», ID 796 - EQS
4) Avslutningsfase: risikovurderingsrapporten skal arkiveres som separat sak i Elements, ikke som post under prosjektet. Navngivning er beskrevet i Risikostyring av informasjonssikkerhet.
Risikotiltak som ikke er avsluttet ved prosjektslutt, overleveres til linjen (kunde) formelt ved prosjektavslutning. Ansvar for oppfølging plasseres. Se Prosjekt, overlevering til kunde.
Personvern i IKT-løsninger (DPIA)
Lovverket stiller krav til konfidensialitet, integritet og tilgjengelighet av informasjon. I tillegg tas sporbarhet ofte med. Dette er beskrevet i Norm for informasjonssikkerhet og personvern i helse og omsorgstjenesten, eller bare «Normen». Selv om prosjektet/løsningen ikke utløser behov for DPIA så bør man ha fokus på personvern i alle fasene.
Hva
En personvernkonsekvensvurdering (DPIA) skal sikre at personvernet til de som er registrerte i løsningen ivaretas.
For hvilke prosjekter/releaser skal DPIA gjennomføres
Fasilitering av Personverkonsekvensvurdering (DPIA) beskriver når en DPIA skal gjennomføres, og når den ikke skal gjennomføres. Det er dataansvarlig som er ansvarlig for å beslutte om DPIA skal gjennomføres, eller ikke.
Når
· Det bør tas en første vurdering i prosjektets konseptfase om DPIA kan være aktuelt å gjennomføre for prosjektet.
· Etter prosjektoppstart: starte dialog med Hemit sin juridiske rådgiver så tidlig som mulig, og personvernombud i aktuelle HF.
· Selve gjennomføringen av DPIA gjøres i sammenheng med ROS-analyse, eller i etterkant når risikonivåer er definert.
Hvordan
1) Konseptfase:
o Vurder om prosjektet innebærer at personopplysninger skal lagres, og om det kan dreie seg om «særskilte personopplysninger» (tidligere kalt sensitiv). Dette kan gjøres i prat med juridisk rådgiver.
o I tilfelle ja, ta høyde for DPIA som leveranseprodukt og milepæl i prosjektplanen. DPIA kan være tidkrevende.
o Dersom personopplysninger skal behandles av KI i et system, er det ekstra skjerpende krav til DPIA
2) Planleggingsfasen:
o Ta en initiell prat med Hemit sin juridiske rådgiver om den databehandlingen av personopplysninger som man ser for seg med den tenkte løsningen.
o Undersøk om det tidligere er gjennomført DPIA for en lignende behandling og om det i så fall kan gjenbrukes
o Identifiser hvilke HF som er dataansvarlig(e) for personopplysningene i løsningen. Det kan være flere dataansvarlige, inkludert Hemit.
§ Få avklart med HF navn på hvem som skal inneha rollen dataansvarlig for løsningen (en fra hvert HF). Dette kan typisk være systemeiere.
o Finne ut om DPIA skal gjennomføres eller ikke, og metode for gjennomføring.
§ Hvis kap. B1 (Indikasjoner på at personvernkonsekvensvurdering må gjennomføres) klart tilsier at det er nødvendig å gjennomføre DPIA, trengs ikke noen videre saksbehandling med beslutning på dette.
§ Hvis det er flere dataansvarlige: Send saken til FORD for behandling i spørsmålet om å gjennomføre DPIA. Hvis det er ett foretak som er dataansvarlig, er det denne som tar beslutning om DPIA eller ikke. Se beskrivelse av saksgang i Fasilitering av Personverkonsekvensvurdering (DPIA).
3) Gjennomføringsfase:
o Før utlysing av anbud: sikre krav til personvern i løsningen, se Prosjektmetodikk, kravspesifisering. Man bør involvere Hemit sin juridiske rådgiver i kravprosessen, og gjerne personvernombud hos berørt HF. Vær oppmerksom på hvor leverandører behandler personopplysninger. Selv om det ikke er høy risiko for personvernet til den registrerte og det ikke gjennomføres DPIA, så er likevel prosjektet pliktig til å ivareta «privacy by design».
o Gjennomføring av DPIA, dersom det er besluttet at skal utføres: Dette beskrives i Fasilitering av Personverkonsekvensvurdering (DPIA) og Veileder for utfylling av mal for personvernkonsekvensvurdering (Ikke tilgjengelig):
§ Bestem deltakere, og få inn fasilitator til å lede prosessen. Det er helt avgjørende at medarbeidere som sitter nærmest bruken av systemet må være med i vurderingene av personvernrisiko.
§ Gjennomfør DPIA workshop og fyll da ut DPIA-mal, DPIA-risikomatrise og et DPIA-skjema etter oppskrift i prosedyren Fasilitering av Personverkonsekvensvurdering (DPIA).
§ I de tilfeller det skal innhentes uttalelse fra andre interessenter, skal dette gjøres av deltakere fra dataansvarlig.
§ Etter at DPIA er fylt ut, følg videre prosess mot FORD og Personvernombud beskrevet i Fasilitering av Personverkonsekvensvurdering (DPIA)
§ Ferdigstilling av rapport: innhentede uttalelser innarbeides i rapporten.
§ Godkjenning:
· DPIA godkjennes av områdestyret dersom det gjelder flere foretak.
· DPIA-fasilitator ved Hemit sender saken til kontaktperson i det enkelte HF for videre behandling og beslutning av ledelsen i HF, dersom DPIA gjelder ett foretak.
· Ved godkjenning skal følgende vurderes:
o Avgjøre om de valgte risikoreduserende tiltakene, restrisikoen og handlingsplanen er akseptabel.
o Beslutte og begrunne om:
§ Behandlingen er godkjent
§ Behandlingens oppstart er betinget av forbedringer. I slike tilfeller må ny DPIA fremlegges.
§ Behandlingen ikke kan gjennomføres. Dersom et HF ikke godkjenner databehandling hos seg, kan ikke databehandlingen skje, dvs da kan ikke løsningen tas i bruk i dette HF’et.
Risikovurderinger dersom løsninger inneholder Kunstig Intelligens (KI)
Dersom et system som skal anskaffes eller utvikles inneholder KI er det ekstra risikovurderinger som må gjennomføres, dette kommer i tillegg til ROS og DPIA beskrevet over.
Hva
1. KI-konsekvensvurdering. Skal gjøres av alle KI-løsninger før de tas i bruk.
2. FRIA (Fundamental Rights Impact Assessment). Skal gjøres av alle høyrisiko KI-systemer. Kontakt sikkerhetsrådgiver eller jurist i Hemit for å finne ut av om systemet er høyrisiko. Som veiledning til hurtig screening av risikoklassifisering så kan det antas å være høyrisiko dersom noe av følgende gjelder:
o Dersom systemet benyttes til diagnostikk, behandling eller prioritering av pasienter
o Det brukes i kritisk infrastruktur eller medisinsk utstyr (CE-merking)
o Det behandler biometriske data
o Det påvirker grunnleggende rettigheter
o Det faller inn under forhåndsdefinerte høyrisikoområder i henhold til KI-forordningen
Dersom noen av disse punkter slår til, er det viktig å sikre at de blir grundig vurdert og håndtert på en forsvarlig måte.
Se Retningslinje for sikker og ansvarlig bruk av kunstig intelligens i Hemit (Ikke tilgjengelig) for ytterligere beskrivelse.
Når og for hvilke prosjekter
· Det bør tas en vurdering allerede i prosjektets konseptfase om det som skal anskaffes eller utvikles inneholder KI
· Under anbudsfase bør det gjennomgås på nytt med alle tilbydere hvorvidt det de tilbyr er en KI-løsning eller om den inneholder deler av KI
Hvordan
Kontakt sikkerhetsrådgiver og personvernombud i foretaket og finn ut av hvordan KI-konsekvensvurdering og FRIA kan gjennomføres. Foreløpig er det ikke lagd rutiner for det.
Det er generelt anbefalt å gjøre
KI-konsekvens-vurdering og FRIA samtidig som DPIA og risikovurdering av
informasjonssikkerhet (ROS) utføres.
Referanse
· PRINCE2-metodikk, Ledelse av vellykkede prosjekter med Prince2, ISBN 9780113315604
· ISO 31000:2018, Risikostyring, prinsipper og retningslinjer
· Styrende dokumenter: Dokumentkategori «Informasjonssikkerhet og personvern» - EQS
· KI-forordningen på 1-2-30 minutter | Datatilsynet
· Ny risikovurdering - Helsedirektoratet (om risikovurderinger ved bruk av kunstig intelligens i helse- og omsorgstjenesten)