Fire kommuner på Helgeland ville gå sammen om en felles sensitiv driftsentral for pleie/omsorg, sosial og barnevern. En av kommunene skulle ivareta vertskapsrollen som drifter av løsningen (databehandler). Som del av et Høykom-prosjekt ble det derfor påkrevet å utforme en Service Leverings Avtale (SLA) som innfrir Helseregisterloven og Personlovgivningen i et slikt samarbeide. I forutsetningene for tildeling av midlene skulle det lages en veileder/mal som kunne være et mønster for andre kommuner i et slikt samarbeide. Forfatter er personvernombud for disse fire kommunene, og det var derfor naturlig at denne delen av prosjektet ble ledet av undertegnede. Foruterom de samarbeidende kommunene (Grane, Hattfjelldal, Hemnes og Nesna) har Datatilsynet ved Johan Braar Larsen gitt viktige innspill til produktet. Det er også hentet noen ideer fra et tidligere prosjekt i Vestfold. Veilederen er ment å bygge på allerede egnede standardavtaler. Håper dette dokumentet kan være til nytte for andre kommunesamarbeid hvor personvern skal ha fokus.

Med vennlig hilsen

personvernombud Alf Leinan

Innledning

Behandlingsansvarlig sitt ansvar

Behandlingsansvarlig har ansvaret for at opplysningene kun brukes til de behandlinger som er besluttet, og at sikkerheten er som han har besluttet. Når den behandlingsansvarlige benytter andre parter til å utføre oppgaver for seg slik at dette kan ha betydning for hans egen behandling av personopplysninger krever loven bruk av avtaler slik at behandlingsansvarliges ansvar fortsatt blir ivaretatt.

Ved bruk av databehandlere er det viktig å sørge for at disse kun utfører de behandlinger som er bestemt og at avtaleparten ikke bruker opplysningene til noe annet, her er det også viktig at man forbereder et eventuelt opphør av avtaleforholdet med tilbakelevering og sletting av opplysningene.

Når det gjelder sikkerhet har databehandleren et lovpålagt ansvar for å følge sikkerhetsbestemmelsene, men behandlingsansvarlig skal søre for at dette gjennomføres i samsvar med sine egne sikkerhetskrav. Generelt er utfordringen at det benyttes en avtalepart siden behandlingsansvarlige ikke har tilstrekkelig ressurser eller kompetanse til å gjennomføre det hele selv. Her er det ofte en god løsning at behandlingsansvarlig lager en kravspesifikasjon og databehandleren dokumenterer en løsingsbeskrivelse og denne legges til kontrakten som et pålegg om hva parten leverer.

Når det gjelder andre parter som for eksempel leverandører av andre utstyr / programvare eller leverandører av sikkerhetstjenester er prinsippene de samme, men den teknologiske kompetanse-utfordringen kan bli enda vanskeligere å håndtere. Kravene kan tydeliggjøres ved akseptkriterier, tilsvarende det som er i bransjenormer (eller kommuneveilederen), men selv dette medfører at det må gjøres valg ved kontraktsinngåelse og nye valg senere for å korrigere for hendelser. Dessuten pålegges behandlingsansvarlige å kontrollere at parten ivaretar sine oppgaver også fordi en rekke parter ikke har et selvstendig plikt til å etterleve lovens krav til ”internkontroll”.

Husk også man har parter som skal utfører oppgaver som ikke er relatert til behandling av personoppysninger, i slike enklere tilfelle skal behandlingsansvarlig bruke avtale for å forsikre seg om er at disse gjøremål ikke skal medføre noen trusler mot personopplysninger man behandler.

Databehandler som utfører IT-driftsoppgaver.

Her tenkes det på en datasentral eller ASP-leverandør, men det kan også andre som bruker datautstyr for å gjøre oppgaver som feilretting eller korrigering av data på vegne av den behandlingsansvarlige. Personopplysningslovens §15 stiller krav om avtale og §13 pålegger databehandleren å etterleve kap. 2 i forskriftene, men loven pålegger ikke databehandler selv å velge de samme akseptkriterier som behandlingsansvarlig selv velger. Husk at avtalens hensikt er å pålegge databehandleren å kun utføre avtale ”maskinelle operasjoner” på de opplysningene som behandlingsansvarlig har ansvaret for. Videre er avtalens hensikt å sørge for at Databehandleren har det sikkerhetsnivå behandlingsansvarlig krever at databehandleren skal ha til sist skal behandlingsansvarlige forsikre seg om at databehandleren virkelig gjør som avtalt.

Databehandler som utfører manuelle behandlinger

Her tenkes det på en part eller leverandør som gjør også manuelle behandlinger av opplysninger (lønningsfører og lignende) for den behandlingsansvarlige.

Her er utgangspunktet når det gjelder lovverkets krav i §13 og §15 det samme som i forrige avtale, så det blir først og fremst her i tilleg å ha fokus på de ”manuelle ”behandlingene av opplysningene. I tillegg kommer selvfølgelig det viktige kravet om at opplysninger ikke skal utleveres eller brukes til andre formål og ”slettes” ved avtaleopphør. Her blir ofte utfordringen å klare konfigurasjonskontroll for databehandleren kan ofte benytte brukerutstyr som ikke er eiet og kontrollert av den behandlingsansvarlige.

Om avtaler og interkommunalt samarbeide.

Det er helt avgjørende at ekstern databehandler i slike samarbeid er en egen juridisk enhet, enten som et eget juridisk selskap eller at en av kommunene databehandler for andre kommuner på enkelte områder.

Oppbygging av dette dokumentet

De fleste standardavtalene som omfatter ASP- eller IT drifts-avtaler mangler reguleringer som ivaretar personvernet slik som omtalt i innledningen. Skal en etablere samarbeidsordninger der en setter bort driften av IT-løsninger eller hvor flere institusjoner samarbeider om felles løsninger må det opprettes en Service Leverings Avtale (SLA) som ivaretar personverninteressene. Dette dokumentet omfatter endringer eller tilegg som må inn i slike driftsavtaler for å ivareta dette dersom dette ikke allerede er dokumentert.

Dette dokumentet inneholder derfor tre kapittel:

· Kap. I – Endringer og tillegg til standardavtale

· Kap. II - Omforent spesifikasjon av SLA -tjenestene med forutsetninger og vilkår i bilag 1

· Kap. III – noen eksempler til bilag 1

Ad. Kap I: denne teksten innarbeides i endringskatalogen til standardavtalen, dersom dette ikke er regulert i avtalen.

Ad. Kap. II: denne teksten er en disposisjon for bilag 1 hvor den blå kursive teksten overskrives med deres løsning.

Ad. Kap. III: vises noen eksempler på momenter som kan innarbeides i bilag 1.

Alle databehandlere og leverandørtyper ( av kommunikasjonstjenester, sikkerhetsutstyr og programservice gjennom elektronisk tilkobling) slik som beskrevet i innledningen, må forholde seg til de punktene som er beskrevet i kap I-II.

Kap I: Endringer og tillegg til den generelle avtaleteksten

Definisjoner

Behandlingsansvarlig: Den som bestemmer formålet med behandlingen av personopplysninger og hvilke hjelpemidler som skal brukes

Databehandler: Den som behandler personopplysninger på vegne av den behandlingsansvarlige

Personopplysningsloven Forkortes i dette dokumentet til POL

Personopplysninsforskriften Forkortes i dette dokumentet til POF

Helseregisterloven Forkortes i dette dokumentet til Her

Service Leverings Avtale (SLA)

I tillegg til valgte standardavtale fungerer Avtalen som en Service LeveringsAvtale (SLA) som dekker POL og Her sine krav til ASP’en som Databehandler. Henviser spesielt til POL §15 Og Her §18:

”En databehandler kan ikke behandle personopplysninger på annen måte enn det som er skriftlig avtalt med den behandlingsansvarlige. Opplysningene kan heller ikke uten slik avtale overlates til noen andre for lagring eller bearbeidelse. I avtalen med den behandlingsansvarlige skal det også gå frem at databehandleren plikter å gjennomføre slike sikringstiltak som følger av § 13.”

Planlegge konkrete behandlinger og forhindre andre

POL §13 krever at behandlingene skal være dokumenterte og igjen annen part skal ha tilgang til behandlingene enn dem som er regulert i denne avtale. I BILAG 1.1 hvor behandlingene er beskrevet skal det derfor være:
- forbud mot enhver egen bruk

- forbud mot utlevering til andre enn dem som fremkommer av denne avtale

- pålegge sletting eventuelt utlevering av data ved avtalens opphør.

Klare ansvarsforhold

POL §15, Her §18 og Personopplysningsforskriften(Pof) §2-15 krever klare formålbeskrivelser og oppgaveavgrensninger. Pof §15 krever videre at Behandlingsansvarlig skal etablere klare ansvars- og myndighetsforhold ovenfor Databehandler. Behandlingsansvarlig skal også ha kunnskap om sikkerhetsstrategien hos Databehandler for å forsikre seg om tilfredsstillende informasjonssikkerhet.

Disse beskrives i BILAG 1.4.

Sikkerhet og regeletterlevelse

Databehandler plikter å gjøre seg kjent med reglene i Pof som vedrører denne Avtalen. Behandlingsansvarlig undersøker dette under årlig strategigjennomgang beskrevet i BILAG 1.5

Avviksrutine

Pof 2-6 krever at behandlingsansvarlig og databehandler skal føre avvik på alle hendelser som er i strid med fastlagte rutiner. Avviksprosedyrene skal beskrives i BILAG 1.6

Konfidensialitet

Databehandler skal gjøre seg kjent med og etterleve innholdet i Pof §2-11. 2-4 ledd. Dette innebærer også å hindre uautorisert innsyn fra de øvrige samarbeidspartnerne. Tiltakene kontrolleres gjennom årlig strategigjennomgang beskrevet i BILAG 1.5

Tilgjengelighet

Databehandler skal gjøre seg kjent med og etterleve innholdet i Pof §2-12. 2-4 ledd. Sikringsrutiner av data beskrives i BILAG 1.9

Integritet

Databehandler skal gjøre seg kjent med og etterleve innholdet i Pof §2-13. 2-3 ledd. Sikringsrutiner av data beskrives i BILAG 1.10

Dokumentasjon og logging

Databehandler skal gjøre seg kjent med og etterleve innholdet i Pof §2-16. Dokumentasjon og loggingsrutinene skal beskrives i BILAG 1.11

Personell

Databehandler skal sikre at eget personell har tilstrekkelig kunnskap for å ivareta informasjonssikkerheten. Databehandler skal også sørge for at en eget personell ikke blir eksponert for opplysninger hvor konfidensialitet er nødvendig og heller ikke annen informasjon som har betydning for informasjonssikkerheten, jmf. Pof 2-11, 1. og 2. ledd.

Fysisk sikring

Databehandler skal gjøre seg kjent med og etterleve innholdet i Pof §2-10. Dokumentasjon på fysisk sikring skal beskrives i BILAG 1.12

Risikovurdering

Før løsningen jmf. denne Avtale implementeres i organisasjonen skal behandlingsansvarlig ha gjennomført risikovurdering jmf. Pof § 2-4. Behandlingsansvarlig er også ansvarlig for å fastsette kriterier for akseptabel risiko. Disse kriteriene skal gjøres kjent for Databehandler som må ta høyde for dette under sin løsningsspesifikasjon.

Risikovurderingen skal være dokumentert.

Databehandler er pliktig til å assistere behandlingsansvarlig i risikovurderingen dersom behandlingsansvarlig krever dette.

Konfigurasjonskontroll

Pof 2-7, 4-ledd sitat ” Konfigurasjonen skal dokumenteres og ikke endres uten autorisasjon fra den behandlingsansvarlige.” Behandlingsansvarlig skal i denne sammenheng påse at konfigurasjonskontrollen gjennomføres slik at det ikke foregår utilsiktet utlevering og tilgang til informasjon mellom de samarbeidende partnere. Komponentbeskrivelse, konfigurasjonskart og soneinndeling skal beskrives i BILAG 1.7

Underleverandører og personvern

Det er ikke tillatt å utlevere eller eksponere personopplysninger til andre underleverandører enn dem som fremkommer av denne avtale. Eventuelle andre partnere skal beskrives i bilag 1.2

Taushetsplikt i forhold til POL

Databehandler skal pålegge taushetsplikt for sine ansatte for personopplysninger hvor konfidensialitet er nødvendig. Taushetsplikten omfatter også annen informasjon som har betydning for informasjonssikkerheten, jmf. Pof §2-9.

Kap II: Omforent spesifikasjon av SLA -tjenestene med forutsetninger og vilkår

Bilag 1

1.1 Beskrivelse av behandlingene som skal utføres.

(Her beskrives hvilke programprodukter som skal betjenes av ASP-leverandøren samt hvilke kommuner som inngår i Avtalen. En tabellarisk fremstilling vil her være egnet)

1.2 Andre parter i avtalen

(Her beskrives eventuelle andre parter i avtalen som kommer som tillegg til kommunene og ASP-leverandøren. Det er også viktig å få frem hvilke leverandørkategori andre parter har i forhold til Avtalen (Databehandler, leverandør u/ databehandleroppgaver, eller annen type partner)

1.3 Opphør av avtalen

(Her beskrives hva som skjer når avtalen opphører – avvikles, tas hjem til kommunen eller overdras av andre ASP-leverandører. Hovedfokuset må her rettes mot dataene (personopplysningene))

1.4 Ansvar og myndighet

(Her beskrives hvem som er behandlingsansvarlig, sikkerhetsansvarlig, IKT-ansvarlig og databehandler, både for oppgavene i fellesskapet og den enkelte kommune.)

1.5 Årlig strategigjennomgang og konsekvenser av brudd

(Her må det beskrives hvordan behandlingsansvarlig skal forsikre seg om databehandler har tilstrekkelig kjennskap til Pof.

Videre skal det beskrives hvordan behandlingsansvarlig skal skaffe seg kunnskap om sikkerhetsstrategien hos databehandler. Punktet skal også beskrive hvilke konsekvenser sikkerhetsbrudd vil få for databehandler.)

1.6 Avviksprosedyrene

(All bruk som er i strid med fastlagte rutiner skal avviksrapporteres. I et slikt samarbeide må det komme klart frem hvem som rapporterer til hvem for feil i programvare, feil på maskinutstyr, feil i saksbehandling mv.)

1.7 Teknisk Løsning

(Som vedlegg til denne avtale må det lages konfigurasjonskart hvor det fremkommer intern og sikker sone, eksterne tilkoblinger og hvilken del av konfigurasjonen databehandler har ansvar for og hvilken del den enkelte kommune har ansvar for.)

1.8 Konfidensialitet

(Her må det beskrives hvilke rutinene for autorisasjon og tildelingsom er tilrettelagt i samarbeide.)

(Videre hvordan databehandler forhindrer uautorisert innsyn fra uvedkommende av personopplysningene og hvordan elektronisk kommunikasjon er sikret. Dette innebærer også uautorisert innsyn fra uvedkommende som også er ansatt i andre kommuner på driftssentralen, samt uautorisert utlevering fra disse. Sikring av lagringsmedium må også beskrives)

1.9 Tilgjengelighet

(Her må det beskrives hvordan redundans i nettet er sikret, backup rutiner, overvåkning, oppetid - konsekvens, responstid, helpdesk (åpningstider, servicenivå) og alternative kjøringsmuligheter ved for eksempel brann eller alternative manuelle rutiner.

1.10 Integritet

(Her beskrives hvilke rutiner som etableres mot ulike ødeleggende program, eksempelvis virus og lignende. I tillegg må funksjonstester beskrives som sikrer at programmene fungere uten at opplysninger blir feil/endret eller kommer bort.)

1.11 Dokumentasjon og loggrutinene

(Her beskrives hva som er utformet av ulike instrukser for databehandler og rutiner for logging av forsøk for uautorisert bruk av systemene.)

1.12 Fysisk sikkerhet

(Her beskrives hvordan en rent fysisk hindrer uautorisert adgang til systemene samt påvirkninger i driftsmiljøet som kan skade personopplysningene)

Kap III: Noen eksempler til BILAG 1

1.1 Beskrivelse av behandlingene som skal utføres.

Eksemplene er hentet fra beskrivelser der hvor flere kommuner samarbeider.

Kommune	Pleie/omsorg	Sosial	Barnevern
Kommune 1	X	X	X
Kommune 2	X	X
Kommune 3		X	X
Kommune 4	X	X	X

1.3 Opphør av avtalen

Behandlingsansvarlig i de respektive kommuner er ansvarlig for å etablere nye ansvar og myndighetsforhold dersom en annen databehandler overtar databehandlingen eller tas hjem til egen kommune.

Dersom en annen databehandler overtar databehandlingen skal det etableres nytt SLA-dokument som omfatter de samme områder som beskrevet i denne avtale samt innfrir POL §15, Her §2-18 og POF §2.

Dersom kommunen velger å utføre databehandlertjenesten i kommunal regi skal sikkerhetshåndboken for egen kommunen i sin helhet gjøres gjeldende.

Registrene vil alltid være de respektive kommuners eierskap når de befinner seg hos databehandler og skal fritt tilbakeleveres ved opphør av avtalen.

1.4 Ansvar og myndighet

Behandlingsansvarlige

Behandlingsansvarlig bestemmer formålet med behandlingen og er formelt ansvarlig for at behandlingene utføres i henhold til Lov om behandling av personopplysninger og tilhørende forskrifter.

Behandlingsansvarlig skal forsikre seg om at databehandler har tilstrekkelig kjennskap til egne krav og gjeldende myndighetskrav for behandling av informasjon (jmf. POF §2-15 - 4. ledd) og jevnlig forsikre seg om at driftsteamets sikkerhetsstrategi er tilstrekkelig og at den følges. Dette gjøres ved at sikkerhetsansvarlig innkalles til møter der sikkerhetsstrategien hos databehandler er tema.

Respektive rådmenn er behandlingsansvarlig for egen kommune.

Databehandler tekniske løsninger

Driftsteamet er databehandler for tekniske løsninger i henhold til Lov om behandling av personopplysninger, og forplikter seg til å kjenne og følge gjeldende myndighetskrav for behandling av sensitive personopplysninger. Henvises til SH – ”Prosedyre for databehandlere” kap. 13 samt POL §15 og POF §2-15. Driftsteamet er underlagt behandlingsansvarlig (rådmann) i vertsskarpkommunen.

Dette innebærer bl a :

- Ansvar. Driftsteamet er ansvarlig for sikkerhetsbrudd for eget personale og brudd som har oppstått gjennom tilkopling av utstyr. Det er ikke anledning til å oversende opplysninger til tredje part uten behandlingsansvarlig sitt samtykke.

- Taushetsplikt. (POF §2-9) Driftsteamet sitt personale skal undertegne taushetserklæring. De som undertegner taushetserklæring skal samtidig gjøres kjent med hva dette innebærer.

- Sikkerhetsløsning. Driftsteamet skal til enhver tid ha en organisatorisk og teknisk sikkerhetsløsning som tilfredsstiller kommuneveilederen. Denne skal kunne dokumenteres overfor Datatilsynet.

Databehandler i saksbehandlingsøyemed

Dette er en mulighet men må utredes i hvert enkelt tilfelle.

Sikkerhetsansvarlig

Sikkerhetsansvarlig er kontaktleddet mellom behandlingsansvarlig og databehandler i alle større saker som vedrører informasjonssikkerheten.

*Sentrale oppgaver for sikkerhetsansvarlig*	Felles oppgaver	Kommune 1	Kommune 2 kommune	Kommune 3	Kommune 4
Motta og følge opp gjennomførte sikkerhetsrevisjoner fra systemeiere
Godkjenne større endringer i driftsteam infrastrukturen
Årlig arrangere et sikkerhetsforum for systemeiere, systemansvarlige og driftsteam
Minimum årlig gjennomføre risikovurdering av sensitiv driftssentral
Gjennomføre og følge opp ledelsens gjennomgang iht fastlagt prosedyre

Systemeier

Systemeier er den personen som i kraft av sin lederstilling er ansvarlig for det informasjonsmessige innhold i et system, og har ansvaret for at systemet utnyttes til beste for kommunen. Systemeier er også ansvarlig for at informasjonssikkerheten blir ivaretatt for sitt system.

*Sentrale oppgaver for systemeier.* Det skal gjennomføres brukermøter for systemeiere minimum hvert halvår hvor også driftsteam innkalles. Møtested etter avtale. Det skrives referat fra alle møter.	Felles oppgaver	Kommune 1	Kommune 2 kommune	Kommune 3	Kommune 4
Gjennomføre sikkerhetsrevisjon iht til personopplysningsloven og forskrift
Påse at det er utarbeidet driftsrutiner og at de blir fulgt
Peke ut systemansvarlig og at denne har en reell mulighet til å utføre sine oppgaver
Innarbeide budsjettmidler for videreutvikling av fagsystemer
Sørge for at det finnes et opplæringstilbud
Optimal utnyttelse av fagsystemet
Følge opp alvorlige brudd på informasjonssikkerheten

Systemansvarlig

Systemansvarlig er ansvarlig for bl.a. systemets funksjonalitet og virkemåte, fortløpende kontakt med leverandør, brukeropplæring og tilhørende arbeidsrutiner.

Sentrale oppgaver for systemansvarlig. Det gjennomføres brukermøter for systemeiere minimum hvert halvår hvor også driftsteam innkalles. Møtested etter avtale. Det skrives referat fra alle møter.	Felles oppgaver	Kommune 1	Kommune 2 kommune	Kommune 3	Kommune 4
Opprette brukere på oppdrag fra autorisasjonsansvarlig og tildele disse rettigheter i fagsystemet
Ivareta løpende kontakt med systemets leverandør
Koordinere og planlegge oppgradering av programvaren
Utarbeide opplæringsplaner og gjennomføre kurs
Tilpasse kodeverk og maler
Bistå brukerne ved feil og utnyttelsen av fagsystemet

Databehandler

IT-Konsulentene utfører delvis oppdrag i egen kommune samt fellesoppgaver i driftsteamet. Til sammen representerer dette oppgavene for databehandler beskrevet nedenfor

*Sentrale oppgaver databehandler*	Driftsteamet	Kommune 1	Kommune 2 kommune	Kommune 3	Kommune 4
Installasjon, service og vedlikehold av arbeidsstasjoner inkludert programvare
Installasjon, service og vedlikehold av periferutstyr (skrivere, plotter, skanner etc)
Installasjon, service og vedlikehold av lokal nettverkselektronikk
Drift av lokalt nettverk og internkabling i kommunene
Drift av ytre brannmur
Drift av indre brannmur (sammen med NHN)
Administrasjon av sertifikater i RSA løsning
Administrasjon av brukere/grupper i operativsystem, herunder brukeridenter, passord og rettigheter
Administrasjon og drift av SQL database
HelpDesk for sluttbrukere vedr profiler, brukeridenter, passord, rettigheter, katalogtjenester
HelpDesk for sluttbrukere av MS Office, kontorstøtte programvare
Få inn relevante sikkerhetskrav i avtaler og kontrakter med leverandører
At det finnes tilfredsstillende avtaler for drift, vedlikehold og videreutvikling
Konfigurasjonskontroll av arbeidsstasjoner
Utarbeide og etterleve rutiner for sikkerhetskopiering og evt tilbakelegging av data, konfigurasjonskontroll, adgangskontroll og håndtering av leverandører, opprette endre og slette brukere, håndtering av passord, utilsiktet avbrudd.
Merkantil oppfølging leverandører, div adm, økonomi, budsjett, fakturering

Alle brukerne

· Alle brukere er pliktig til å sette seg inn i og følge gjeldende rutiner for bruken av informasjonssystemene.

· Alle brukere skal bidra til å melde avvik når det er nødvendig.

· Alle brukere må lagre og logge seg ut når en blir borte mer enn 1 time fra arbeidsstasjonen.

Utnevnte systemeiere og systemansvarlige

*Fagsystem*	*Systemeier*				*Systemansvarlig*
*Fagsystem*	Kommune 1	Kommune 2	Kommune 3	Kommune 4	Kommune 1	Kommune 2	Kommune 3	Kommune 4
*CosDoc*	Virksomhetsleder Institusjonsbaserte tjenester	Faggruppeleder HBO			Fagutviklings-sykepleier Sissel Martiniussen	Faggruppeleder HBO
*Sosial*	Virksomhetsleder Rådgivninsgstjenesten	Socio brukes ikke	Helse- og sosialsjef		Sosialkonsulent Gjermund Dreng	Socio brukes ikke	Virksomhetsleder familie- og sosial
*Barnevern*	Virksomhetsleder Rådgivninsgstjenesten	Faggruppeleder Sosial	Helse- og sosialsjef		Barnevernkonsulent Mona Evju	Faggruppeleder Sosial	Virksomhetsleder familie- og sosial

Utover dette kan kommunene utpeke lokale superbrukere etter behov.

1.6 Avviksprosedyrene

Formål

Bruk av informasjonssystemet som er i strid med fastlagte rutiner, og sikkerhetsbrudd, skal behandles som avvik. Formålet med avviksbehandling er å bringe avviket til opphør, gjenopprette normal tilstand, og hindre gjentagelse.

Avviksrapportering

Brukerne rapporterer alle avvik til HelpDesk som har til oppgave å:

· Motta og registrere meldinger om avvik

· Sørge for at ethvert avvik får en klart identifisert eier

· Følge opp at avvik blir håndtert til avtalt tid

· Bekrefte ferdigbehandling av avvik

Dersom avviket har medført uautorisert utlevering av personopplysninger hvor konfidensialitet er nødvendig, skal Datatilsynet varsles

Rapporteringssted

Mottak	Dekningstype	Service tid
HelpDesk	Bemannet tjeneste	Man –fre kl 0800 – 1600 ( 15.00)
Hjemmevakt	Ingen bemanning

Retningslinjer for avvikshåndtering

Bruker forpliktelser

Driftsteams forpliktelser

· HelpDesk kontaktes via telefon eller e-post. Bruker kan ta direkte kontakt med HelpDesk.

· Ved registrering av en samtale, vil bruker få et referanse nummer fra HelpDesk. Hvis bruker ikke har fått et slikt nummer, skal bruker anta at samtalen ikke har blitt registrert.

· Brukere som krever ytterligere informasjon om utestående avvik skal kontakte HelpDesk og oppgi referansenummer.

· Når bruker mottar melding fra HelpDesk om ferdigbehandlet avvik, skal bruker bekrefte tilbake via telefon eller e-post at avviket er opphørt.

· HelpDesk vil registrere mottatte avvik og tildele disse et referansenummer. HelpDesk vil svare på e-post eller telefon. Bruker mottar umiddelbart dokumentasjon av registrert avvik pr e-post.

· Tilbakemelding skal skje fortløpende i henhold til prioritet og definerte tidsrammer. Ved ferdigbehandling av avviket skal det gis melding til bruker v/den som har meldt avviket eller i henhold til avtale som ble gjort ved registrering – enten via telefon eller e-post.

· Ethvert avvik som forårsaker at en tjeneste ikke er løst innenfor mål for løsningstid skal resultere i en skriftlig rapport til systemeier som beskriver årsak, løsning og aktiviteter/planer for å hindre gjentakelse.

· Når HelpDesk mottar bekreftelse fra bruker om at avviket er opphørt skal avviket merkes som opphørt og saken som avsluttet.

Alle avvik skal meldes til HelpDesk, også feil i 3.parts programvare. I slike tilfeller avtales om det er HelpDesk eller bruker/systemansvarlig som kontakter leverandør.

Prioritering av avvik

Alle avvik skal meldes til HelpDesk og blir samtidig tildelt en prioritet.

Prioritet	Definisjon	Mål for løsningstid
Høy	Fullstendig bortfall av fagsystem som berører en hel virksomhet/faggruppe	Snarest. Det forutsettes at bruker er tilgjengelig.
Middels	Fullstendig bortfall av fagsystem som berører minimum 1 bruker. Nettverksskriver virker ikke.	4 timer
Lav	Kosmetiske eller trivielle avvik	1 arbeidsuke eller som avtalt med bruker

1.7 Teknisk Løsning

Retningslinjer for endring av programversjoner

Brukerforpliktelser

Driftsteams forpliktelser

· Skriftlige/ elektroniske forespørsler om nye versjoner av program sendes HelpDesk med beskrivelse av begrunnet behov. Slike forespørsler skal være signert av systemeier.

· Større endringer skal være godkjent av sikkerhetsansvarlig.

· driftsteamet vil evaluere forespørsel om nye versjoner av program og anbefale hvorvidt de bør gjennomføres.

· Systemeier vil bli konsultert når det gjelder forslag til oppgradering av program. Endringer av versjoner vil ikke bli foretatt uten systemansvarlig/systemeier sitt samtykke.

· Når systemansvarlig/systemeier og driftsteam er enige om at oppgradering av et program skal foregå utenom avtalt vedlikeholdstid så regnes dette likevel som oppetid.

Beskrivelse og endring av teknisk løsning

Driftsteamet er ansvarlig for oppdatert konfigurasjonskart og løsningsbeskrivelse slik SH kap. 10 beskriver

1.8 Konfidensialitet

Retningslinjer for registrering av nye brukere og for opprettelse eller endring av tilgang til programmer

Brukerforpliktelser

Driftsteams forpliktelser

· For å registrere/slette en bruker og/eller gjøre endringer på eksisterende brukere, skal enhetsleder (autorisasjonsansvarlig) fylle ut eget skjema for dette og oversende driftsteamet.

· Dette gjelder ikke brukerregistrering i fagprogram. Her skal skjemaet sendes til systemansvarlig for fagprogrammet.

· driftsteam vil behandler gyldig forespørsler om nettverk brukerregistreringer /endringsmelding iht rutine for dette. Brukere vil få tilgang senest innen 3 arbeidsdager.

· For nettverk og e-post vil passord bli gjenopprettet innen 1 arbeidstime etter at melding om dette er sendt til HelpDesk.

1.9 Tilgjengelighet

Redundans/Sikkerhet

Alle servere er satt opp med maskinvare RAID og redundante strømforsyninger. I tillegg har database server redundante vifter for i/o og cpu.

Løsningen innholder også antivirus og backup systemer.

Alle servere og nettverkselektronikk i fellespunktet er beskyttet med UPS (Nødstrøm).

Oppetid Konsekvens

Løsningen garanteres en tilgjengelighet > 99.5%. Ved nedetid vil kunden få prisavslag ihht. følgende tabell:

Tabellen under angir terskelverdier for refusjon av vederlaget pr måned. Måleperioden utgjør kalendermåneden det søkes refusjon for samt de to foregående månedene. Refusjonsbeløpet avregnes og fratrekkes på den neste ordinære faktura til Kunden.

Servicenivå tilgjengelighet per lokasjon	Terskler for refusjon	Måleperiode for beregning refusjon	Refusjon	Avregnings-grunnlag for refusjon
99,5%	98,3% - 97,2%	Ett kvartal 2 190 timer	20 %	Én månedsleie
99,5%	97,1% - 96,0%	Ett kvartal 2 190 timer	40 %	Én månedsleie
99,5%	95,9% - 94,8%	Ett kvartal 2 190 timer	60 %	Én månedsleie

Driftsstans som følge av planlagt vedlikehold varsles minimum 48 timer i forveien. Slikt varsel sendes på
e-post i tillegg til at varsling vil bli gitt over telefon. Den enkelte Kommune angir telefonnummer, e-post adresse og kontaktperson. Planlagt vedlikehold vil foregå i tidsrommet 20:00-24:00, dersom ikke fysiske forhold gjør dette umulig.

Responstid

For å ivareta kvalitet på Driftsytelsene skisserer Leverandøren her Responstider i Driftsperioden ved hendelser.

Prioritet	Eksempel på hendelse	Evalueringskriterier	Responstider
Pri 1- Kritisk	Applikasjoner og/eller data er utilgjengelig via Tekniske infrastruktur	Berører mer enn 20% av brukerne	Umiddelbart og senest innen 1 time
Pri 2 - Høy	Driftsforstyrrelser på tjenester og funksjonalitet	Berører mer enn 20% av brukerne	2 timer
Pri 3 – Medium	Feil som medfører at tjenester og funksjonalitet ikke er tilgjengelig	Berører mindre enn 20% av brukerne	6 timer