1. Kravsudarbejdelse

Når man skal udarbejde sikkerhedskrav til leverandøren, bør man dels forholde sig overordnet til leverancen og dels konkret til risikovurderinger af de elementer (informationer, systemer, infrastruktur), der indgår i leverancen

Eksempler på spørgsmål man kan stille til leverancen:

  • Er det en standardiseret eller en specialiseret ydelse?
  • Hvad er kritikaliteten af leverandørens ydelse?

• Er der udarbejdet en risikovurdering med udgangspunkt i risikoen for de registreredes rettigheder?
• Er der en eksisterende risikovurdering, man kan tage udgangspunkt i?
• Skal der udarbejdes en trusselsvurdering i forhold til ydelsen?

På baggrund af leverancens kategorisering og risikoprofil skal man herefter udvælge de nødvendige sikkerhedskrav, som skal indgå i kravspecifikation og udbudsmateriale.

  Billedet illustrerer Fase 1: Kravudarbejdelse

Digitaliseringsstyrelsens kravkatalog til leverandører

Digitaliseringsstyrelsen har udarbejdet et kravkatalog, som er en hjælp og inspiration til at stille relevante sikkerhedskrav ved udbud og indgåelse af it-kontrakter med leverandører.

Hent Digitaliseringsstyrelsens kravkatalog til leverandører

Stil også krav til rapportering

I kravudarbejdelsen bør man tage stilling til, hvilken grad af dokumentation for overholdelse af kravene, leverandøren skal levere. For nogle krav er det nok at henvise til en generel revisionserklæring eller fx et ISO 27001-certifikat. For andre bør man stille krav om rapportering eller om en systemspecifik revisionserklæring baseret på inspektion og stikprøver. Graden af evidens afhænger af den overordnede leverance og de gennemførte risikovurderinger.

Eksempel på leverandørkategoriseringsmodel

Udformningen af krav til leverandørens sikkerhed, rapportering og revisionserklæringer bør stå i relation til leverancens art og kritikalitet.

  Billede af eksempel på model for leverandørkategorisering

Indledende overvejelser om Samarbejdsmodel mellem myndighed og leverandør i kravudarbejdelsen

Det er vigtigt at gøre sig indledende overvejelser om samarbejdsmodellen i kravsudarbejdelsen, især i forbindelse med EU-udbud. Vigtige elementer i dette er blandt andet, at: 

  • fastlægge, hvordan leverandøren skal dokumentere efterlevelse af kravene på sikkerhedsområdet
  • beslutte, hvilke former for afrapportering, der skal leveres fra leverandøren
  • beslutte frekvens og struktur for statusmøder
  • fastsætte krav til revisionserklæringer
  • fastsætte retten til at gennemføre inspektion, audit eller revision hos leverandøren
  • Beslutte grænsefladen mellem myndighed og leverandør i forhold til sikkerhedshændelser og beredskab, herunder sikring af at myndigheden kan rapportere brud på persondatassikkerhed indenfor 72 timer.

Gode erfaringer fra Faxe Kommune

I filmen præsenterer Faxe Kommune nogle af de gode erfaringer, de har gjort sig, når de skal indkøbe nye systemer og skal sikre sig, at leverandøren kan levere den nødvendige sikkerhed.

Hvis du vil have mere inspiration til, hvilke elementer du bør forholde dig til i udarbejdelsen af aftalegrundlaget, kan du finde mere i Center for Cybersikkerhed og Digitaliseringsstyrelsens vejledning Informationssikkerhed i leverandørforhold.

Hent Vejledning: Informationssikkerhed i leverandørforhold

Casebeskrivelse:

I Rigspolitiet har man gjort sig erfaringer med foruddefinerede kravkataloger for informationssikkerhed med nøglekrav til forskellige kategorier af systemer. Herved har man et godt udgangspunkt for kravudarbejdelsen, hvor krav, der er centrale i forhold til bestemte typer af løsninger, er identificeret og beskrevet på forhånd.

Case: Differentierede kravkataloger i Rigspolitiet

Kravkatalog som "menukort"

I Rigspolitiet arbejder man med information og systemer med forskellig klassifikationsgrad og følsomhed.

For at lette arbejdet med at udvælge krav i forbindelse med udbudsarbejdet, har man arbejdet med en model med et antal krav-"menukort" til forskellige grader af klassifikation, som man kan vælge krav fra.
I disse kataloger er nogle krav angivet som "nøglekrav". Princippet bag nøglekravene er ikke, at de er obligatoriske at medtage, men at man er forpligtet til at angive en saglig begrundelse, hvis man fravælger dem (fx på baggrund af en konkret risikovurdering eller fordi kravene ikke giver mening i sammenhængen).

På den måde får man vejledning til at udvælge krav svarerende til informationens eller systemets følsomhed, men har samtidig fleksibilitet i valg af krav, da man ikke har defineret "mindstekrav".
Forskellen på de forskellige "menukort" består i såvel antallet samt indholdet af definerede nøglekrav.