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å blant annet prosedyre Dokumentet er ikke gyldig (Ikke tilgjengelig).
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)
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
ISO 31000:2009 , Risikostyring, prinsipper og retningslinjer:
· Risiko: Virkning av usikkerhet knyttet til et mål (ref. I)
o En virkning er et avvik fra det forventede, positivt og/eller negativt
o Det kan være flere aspekter ved et mål (eks. finansielt, omdømme, helse og sikkerhet, miljø)
o Risiko uttrykkes ofte som en kombinasjon av konsekvens av en hendelse og den tilhørende muligheten for at den skal forekomme (sannsynligheten)
· PRINCE2 definerer risiko som en usikker hendelse, eller et sett av hendelser, som dersom de inntreffer, har en konsekvens for oppnåelsen av prosjektets mål.
o Merk: Begrepet «Risiko» som definert i ISO 31000: 2009 omfatter både negativ (trusler) og positiv (mulighet) risiko. I den norske oversettelsen av PRINCE2-metodikk benytter man begrepet «Usikkerhet» 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".
Arbeidsbeskrivelse
Risikostyring av prosjekt og release
Hva
Dette omfatter risikoer for trusler mot å nå prosjektmål, eller ikke oppnå gevinster. 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 månedlig statusrapporteringen av risiko (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 risikoregisteret på prosjektets Sharepoint-side på Helse Midt-Norges prosjektweb.
For releaser brukes excel-malen vedlagt.
Som alternativt risikoregister i prosjekt kan det brukes excel-mal (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?
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?
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 vedlegg A i Regionalt rammeverk for risikostyring.
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 |
|
|||||
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. Tiltaksansvarlig kan i mange sammenhenger være prosjekt/release-leder.
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, eller ytelse/omfang skal formidles til styringsgruppen
· De viktigste verktøyene for kommunikasjon av risiko er som regel statusrapporten på prosjektweb, saksunderlag til styringsgruppemøter, og prosjektbegrunnelse
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 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.
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-prosjekt
· Ved betydelig avvik fra Hemit Sikkerhetsplan og/eller HMN sikkerhetsprinsipper jf NO-19.
Kravet til at en ROS-analyse skal gjennomføres er skjerpende dersom tjenesten eksponeres mot internett, for sky, eller man tar i bruk 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.
o Ferdigstille risikovurderingsrapporten (fase 5).
o Behandling av ROS-vurderinger:
§ Alle risikovurderinger hvor risiko berører to eller flere helseforetak skal presenteres i Regionalt informasjonssikkerhetsforum (RIF) uavhengig av risikonivå. Saker som meldes til RIF skal være forberedt med saksunderlag (Risikovurderingsrapporten). RIF sitt mandat er å kvalitetsikre risikobilde og identifiserte tiltak, og gi faglige råd til beslutningstakere i linjeorganisasjonen.
§ For IKT-løsninger som skal opp i sky skal risikovurderingen opp til formell behandling i RIF.
§ Risikovurderinger hvor risiko berører kun ett foretak kan presenteres direkte til foretakets informasjonssikkerhetsleder.
o Avgjørelse om aksept av risiko skal tas på riktig ledernivå i hvert berørt HF. Se Risikostyring av informasjonssikkerhet og Dokument «NO-4 Organisering av informasjonssikkerhets og personvernarbeidet i Helse Midt-Norge», ID 796 - EQS
4) Arkivering: 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 overleveres formelt ved prosjektavslutning og 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 registrert 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 prosjektforslag. DPIA kan være tidkrevende.
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 Identifiser hvilke HF som er dataansvarlig(e) for personopplysningene i løsningen. Det kan være flere dataansvarlige, inkludert Hemit.
o 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 Dataansvarlige beslutter om det skal gjennomføres DPIA eller ikke, og metode for gjennomføring. Dersom det i planleggingsfasen ikke er klart om databehandlingen "sannsynligvis medfører «høy risiko»", tas beslutningen senere i prosjektet.
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).
§ Etter at DPIA er fylt ut, skal rapporten sendes over til personvernombud i de aktuelle HF som må gi sin vurdering.
§ Ferdigstilling av rapport: innhentede uttalelser fra personvernombud og eventuelt også de berørte, innarbeides i rapporten.
§ Godkjenning av alle HF: DPIA-fasilitator ved Hemit sender saken til kontaktperson i hvert HF for videre behandling og beslutning av ledelsen i HF. Ledelsen må:
· Avgjøre om de valgte risikoreduserende tiltakene, restrisikoen og handlingsplanen er akseptabel.
· Beslutte og begrunne om:
o Behandlingen er godkjent
o behandlingens oppstart er betinget av forbedringer. I slike tilfeller må ny DPIA fremlegges, eller
o behandlingen ikke kan gjennomføres. Dersom et HF ikke godkjenner databehandling hos seg, kan ikke databehandlingen skje, dvs da kan ikke løsningen taes i bruk i dette HF’et.
Referanse
· PRINCE2-metodikk, Ledelse av vellykkede prosjekter med Prince2, ISBN 9780113315604
· ISO 31000:2009 , Risikostyring, prinsipper og retningslinjer
· Styrende dokumenter: Dokumentkategori «Informasjonssikkerhet og personvern» - EQS