11. Sikkerhed og kvalitetsstyring
Forside - Indhold - Forrige/ Næste
"Vejledning - Kontrakter om komplekse it-ydelser"
11.1 Parternes sikkerhedsforpligtelser
Krav til sikkerhedsniveau er en integreret del af kontrakten og knyttes ofte sammen med krav til kvalitetsstyring. Udover de generelle krav, der er anført i registerlovene, herunder til virksomheder der udfører edb-opgaver for 3. mand, vil der af såvel kundens egne registerforskrifter, som af kundens i øvrigt fastlagte sikkerhedspolitik fremgå krav, som leverandøren skal opfylde. Kunden har ansvaret for, at krav, hvis eksistens han har eller burde have stiftet bekendtskab med, -oplyses til leverandøren i udbudsgrundlaget ligesom leverandøren har ansvaret for at efterspørge de sikkerhedskrav han bør vide, er relevante. Der ses imidlertid ofte kontraktsbestemmelser, hvori der blot står, at leverandøren skal indestå for, at alle leverancer opfylder alle relevante myndighedsforskrifter, og for at alle nødvendige godkendelser fra myndigheder vil kunne tilvejebringes, herunder at leverandørens leverancer ikke vil være til hinder for at opnå Registertilsynets godkendelse af register. I de statslige kontrakter ses dog ofte tillige anført, at leverandøren skal indestå for opfyldelse af interne statslige myndighedsforskrifter.
Det må i kontrakten reguleres, hvem der skal bære den økonomiske risiko for fremkomsten af nye eller uforudseelige forskrifter, som det medfører et ekstra ressourcetræk hos leverandøren at indarbejde. I mangel af modstående bestemmelser må denne risiko bæres af kunden. Leverandøren kan ikke på tidspunktet for underskrift af kontrakt, indestå for opfyldelse af fremtidige krav, eftersom leverandøren af gode grunde ikke kan kende indholdet af endnu ikke meddelte krav, og dermed ikke kan vurdere ressourceforbruget hermed, eller de tekniske komplikationer.
Det er ganske vist ikke udelukket, at leverandøren kontraktsligt kan påtage sig en forpligtelse over for kunden til at følge med i en fremtidig regeludstedelse, men kunden må, hvis han overvejer en bestemmelse herom i kontrakten, vurdere, hvorvidt kunden selv vil kunne løfte opgaven med færre ressourcer og derved billigere for kunden.
Endvidere skal man være opmærksom på, at i henhold til registerloven, er det kunden, der er registeransvarlig for alle data under kundens systemkompleks.
I relation til for eksempel et udviklingsprojekt er det praksis, at kunden i kravspecifikationen angiver de sikkerhedskrav, der skal opfyldes. Kunden er som nævnt ofte den nærmeste til at vurdere, hvorvidt en kravspecifikation omfatter de sikkerhedskrav, som der stilles i medfør af registerloven, herunder i de konkrete registerforskrifter, samt i andre myndigheds forskrifter. Leverandøren skal herefter sikre ved udviklingen, at disse krav opfyldes.
Leverandøren har selvfølgelig en selvstændig forpligtigelse til at opfylde eventuelle krav, der grunder sig i, at leverandøren udfører edb-virksomhed for 3. mand. Disse krav vil fremgå af leverandørens egen registerforskrift.
Udover de angivne offentligretlige reguleringer af sikkerhed skal som nævnt tillige tages højde for de interne sikkerhedskrav, som den enkelte kunde måtte have fastlagt for sin organisation. Disse krav skal tillige meddeles leverandøren. Det er dog ikke alle kunder, der udover krav, der grunder sig i de offentligretlige regler, har fastlagt en sikkerhedspolitik, selv om relevante sikkerhedsregler som indledningsvis nævnt naturligt bør indgå i en kravspecifikation i forbindelse med et udbud. I disse tilfælde følges leverandørens sikkerhedsregler, hvilket bør fremgå af tilbudet. Disse sikkerhedsregler vil selvfølgelig være helt afhængige af hvilke konkrete opgaver leverandøren skal løse for kunden. Uagtet leverandøren for eksempel alene skal foretage overvågning af kundens eksisterende driftsmiljø på kundens lokation, er det dog nødvendigt, at der fastsættes kontraktsmæssigt, hvilke sikkerhedsregler der skal følges.
Den foreslåede bestemmelse nedenfor tager udgangspunkt i, at leverandøren blandt andet varetager elektronisk databehandling for kunden, hvad enten dette så er hos kunden eller hos leverandøren selv. Såfremt der alene er tale om overvågning af kundens driftsmiljø hos kunden, vil dele af bestemmelsen således være irrelevant.
Kunden skal være opmærksom på, at der skal fastlægges sikkerhedsprocedurer både på leverandørens side og på kundens side. Alene en koordinering af, hvem der opretter brugere i systemet, og hvem der nedlægger brugere i systemet, vil involvere såvel procedurer hos leverandør som hos kunde.
Den kontraktsmæssige formulering kan f.eks. være følgende:
"Sikkerheds- og kvalitetsstyringsforpligtelser
Leverandøren er som edb-virksomhed, der udfører edb-opgaver for tredjemand, omfattet af lov om private registres §20, der omhandler virksomheder, der for offentlige myndigheder eller private virksomheder udfører elektronisk databehandling af oplysninger omfattet af registerlovene.
Leverandøren er dermed ligeledes omfattet af registerlovgivningens bestemmelser om, at der skal træffes fornødne sikkerhedsforanstaltninger mod, at oplysninger i registre misbruges eller kommer til uvedkommendes kendskab.
Leverandørens ydelser er omfattet af leverandørens sikkerhedsrutiner, jf. bilag 9 og kvalitetsstyring på sikkerhedsområdet, og af leverandørens eksterne sikkerheds- revision, der foretager uanmeldt sikkerhedsrevision samt varslet opfølgningsrevision. På anmodning overfor leverandøren kan kunden få en erklæring om den samlede systemsikkerhed og driftssikkerhed fra leverandørens eksterne sikkerhedsrevisor i medfør af Foreningen af Statsautoriserede Revisorers revisionsvejledning nr. 14. Såfremt kunden ønsker en sikkerhedsrapport om kundens system hos leverandøren, udarbejder leverandørens eksterne sikkerhedsrevision en sådan rapport mod særskilt vederlag.
Leverandørens sikkerhedscertificering forudsætter, at den generelle systemsikkerhed, datasikkerhed og driftssikkerhed er på et niveau, som er tilstrækkeligt til, at kundernes revisorer kan bygge herpå ved tilrettelæggelse af revisionen. I den udstrækning det måtte være nødvendigt at forbedre sikkerheden i kundens systemer eller i fysiske installationer hos kunden, eller installationer leverandøren overtager fra kunden for at nå det tilstrækkelige niveau, afholder kunden omkostningerne hertil, [med mindre det drejer sig om forhold, som leverandøren burde have taget i betragtning ved afgivelsen af sit tilbud].
Leverandøren indestår for, at alle krav stillet til kunden, i henhold til den til enhver tid gældende lovgivning eller offentlige pålæg, [og som er meddelt leverandøren skriftligt med rimeligt varsel], vil blive overholdt af leverandøren. [Kunden skal omgående informere leverandøren om eventuelle nye sikkerhedskrav, der er relevante for kundens system]. [Kunden har ansvaret for, at krav, hvis eksistens han har eller burde have stiftet bekendtskab med, oplyses til leverandøren ligesom leverandøren har ansvaret for at efterspørge de sikkerhedskrav han bør vide, er relevante].
Såfremt kunden måtte stille krav af sikkerhedsmæssig karakter herudover, er leverandøren pligtig til at opfylde sådanne med rimeligt varsel og i det omfang dette er teknisk mulig.
Dokumenterer leverandøren, at nye sikkerhedskrav medfører øgede ressourceforbrug for leverandøren, forhøjes vederlaget med det hermed forbundne ressourceforbrug.
Det er planlagt, at udviklingen vil blive omfattet af leverandørens kvalitets- og sikkerhedskrav i løbet af ved overflytning af driften til leverandøren, vil driften fra den ... blive omfattet af leverandørens kvalitets- og sikkerhedskrav.
Kundens sikkerhedsforpligtelser Kunden er registeransvarlig for alle data under kundens systemkompleks.
I bilag 9 samt i Driftservice Håndbogen er beskrevet sikkerhedsforpligtelser påhvilende kunden.
Derudover påhviler der kunden følgende sikkerhedsforpligtelser:...."
For fuldstændighedens skyld bemærkes, at ovenstående formuleringer kan blive ændrede med vedtagelsen af en ny lov om persondata (Databeskyttelsesloven).
11.2 Katastrofeplaner
Ved enhver form for drift af et edb-system er det nødvendigt at forholde sig til, i hvilket omfang der skal være etableret et katastrofeberedskab. Dette gælder således også i situationer, hvor kunden selv forestår driften af sit anlæg. Eftersom omkostningerne til katastrofeberedskab øges i takt med, at kravene til katastrofeberedskabet øges, er det væsentligt, at kunden kritisk gennemgår sine edb-systemer med henblik på at fastlægge den maksimale nedetid for det enkelte edb-system, som kunden kan fungere under.
Såfremt nedetid er praktisk talt uacceptabelt, er det nødvendigt at sikre sig etableringen af en såkaldt "varm backup". Det betyder, at der hele tiden er et praktisk talt identisk system klar på et andet anlæg. Dette indebærer samtidig, at dette system løbende skal opdateres på såvel datasiden som på systemsiden.
I de situationer hvor en kunde har behov for "varm backup" gælder dette ofte ikke alle edb-systemerne. Det kan for eksempel tænkes, at kundens tekstbehandlingssystemer, økonomisystemer og lignende systemer, der alene er til intern administrativ brug, kan være utilgængelige i længere tid, uden at det fundamentalt hindrer kunden i at udføre sin virksomhed.
Det samme kan gælde informationssystemer, der af kunden stilles til rådighed for 3. mand. Dette forudsætter dog, at kunden i sine kontrakter med 3. mand har gjort opmærksom på, hvilken tilgængelighed der ville være til informationssystemerne i en eventuel katastrofesituation. Det kunne være, at disse informationssystemer for nogle af brugerne er afgørende i deres virksomheder.
Såfremt det er en leverandør, der skal forestå driften enten på eget anlæg eller på kundens anlæg, er det således væsentligt, at det i kontrakten fastlægges hvilke katastrofeplaner, der skal være gældende.
Kunden bør derfor i kontrakten opdele sine edb-systemer i kategorier efter det tidsmæssige behov for, at driften er genetableret i en katastrofesituation. Der kan tænkes en kategori med "varm backup", en kategori, hvor driften skal være etableres i løbet af få døgn, en kategori, hvor driften skal være etableret inden for nogle uger, og en kategori, hvor driften blot skal etableres på et reserveanlæg i takt med, at kapacitet og ressourcer er tilvejebragt.
Dernæst skal der i kontrakten fastsættes, at der skal udarbejdes en katastrofeplan, der beskriver alle aktiviteter forbundet med reetableringen. Der skal udarbejdes en katastrofeplan på såvel leverandørens side som på kundens side. Dernæst skal der fastlægges hvor ofte denne plan skal afprøves, hvilket oftest er én gang årligt.
Endvidere skal der foretages en vurdering af behovet for ændring af katastrofeplanen ved eventuelle ændringer i kundens systemkompleks. Alene en forøgelse af kapaciteten ved den daglige drift kan give anledning til ændringer i katastrofeplanen. Vurderingen heraf bør ske inden ændringen implementeres i produktionssystemet.
Derudover bør kunden fast én gang om året vurdere, om der er behov for en ændring af katastrofeplanen. Uanset at der ikke er sket nogle ændringer i edb-systemet, kan ændringer i kundens organisation eller opgaveområde medføre behov for ændring af katastrofeplanen.
Eftersom de konkrete katastrofeplaner vil afhænge af såvel IT-miljøets karakter, som af kundens "forretning" kan det være vanskeligt at udarbejde en standardskabelon for en kontraktmæssig bestemmelse herom.
I overensstemmelse med udbudsmaterialets specifikation af, hvilket niveau af katastrofe backup, der skal være på kundens enkelte dele af systemet, skal der udarbejdes en katastrofeplan, indeholdende blandt andet specifikation af, hvordan etableringen af katastrofeberedskabet foregår, proceduren ved vedligeholdelse af katastrofeplan, den årlig test af planen, hvordan proceduren er i en faktisk katastrofesituation, hvilket serviceniveau der vil være ved backup drift, betalingen for disse forhold i overensstemmelse med tilbudet, og opsigelsesbestemmelser. Under de enkelte aktiviteter er det særdeles væsentligt at få specificeret, hvilke opgaver kunden skal varetage, og hvilke opgaver leverandøren skal varetage.
Eftersom det ses, at katastrofe backup etableres af leverandører i udlandet på store backup centre, er det væsentligt at være opmærksom på som offentlig myndighed, hvorvidt ens data må lagres i udlandet, eventuelt efter tilladelse fra Registertilsynet.
Kontraktmæssigt kan forholdet eksempelvis beskrives på følgende måde
"En katastrofesituation foreligger, når driften afbrydes og ikke indenfor .. timer kan genetableres på den hidtidige lokation.
Kunden har kategoriseret sin IT-drift i én af følgende 3 kategorier:
[1. (En på forhånd fastlagt og beskrevet del af kundens samlede drift) skal være i drift på back-up anlæg i løbet af .. timer, medens resten skal være i drift på reserveanlæg hurtigst muligt og inden .. uger.] Der udarbejdes detaljeret katastrofeplan, som beskriver alle aktiviteter forbundet med reetableringen. Planen afprøves årligt. Som led i planlægningen afdækkes kritiske komponenter, som eventuelt skal anskaffes i reserve, for at sikre kort reetableringstid.
[2.Kundens samlede IT-drift skal være i drift på reserveanlæg hurtigst muligt og inden .. uger.] Der udarbejdes en rimeligt detaljeret katastrofeplan, som afprøves så langt, at det sikres, at reetableringen er mulig i praksis. Som led i planlægningen afdækkes kritiske komponenter, som eventuelt skal anskaffes i reserve, for at sikre kort reetableringstid.
[3.Kundens IT opgaver sættes i drift på reserveanlæg i takt med, at kapacitet og ressourcer tilvejebringes]. Der udarbejdes kun efter særlig aftale en summarisk katastrofeplan for kunden. Afprøvning begrænses til at sikre, at reetablering er mulig i praksis.
[Kunden betaler en i tilbudet fastsat løbende afgift til backupanlæg, planlægning og afholdelse af test (kategori 1)]. [Kunden betaler for det dokumenterede ressourceforbrug - i overensstemmelse med kontraktatens principper for omkostningsberegning, jf. bilag 10 - til planlægning og afholdelse af test (kategori 2 eller 3)]. [Omkostningerne anført ovenfor indgår således ikke i vederlaget i §12].
Kunden og leverandøren udformer katastrofeplan og plan for data backup i fællesskab. Såfremt ingen data backup plan foreligger, tages volume backups en gang ugentligt. De ugentlige backups gemmes i .. generationer. En backup pr. måned gemmes i .. generationer.
Ved eventuelle ændringer i kundens systemkompleks, herunder konfigurationsændringer og implementering af ny programmel, vurderer kunden, inden ændringen implementeres, om det giver anledning til ændring af katastrofeplanen.
Katastrofeplanen vurderes i øvrigt en gang årligt af kunden med henblik på, om der er behov for ændring af katastrofeplanen.
[Kunden har ret til en [årlig] uvarslet afprøvning af beredskabet]"
|
Elektronisk publikation fremstillet af J.H. Schultz Grafisk A/S efter Forskningsministeriets retningslinier |