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?
  • Er der særlige forpligtigelser, som er defineret af fx EU og dansk lovregulering, gældende standarder, GDPR, NSIS og NIS2?

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 opslagsværk om sikkerhedskrav til leverandører

Digitaliseringsstyrelsen har udarbejdet et opslagsværk med formål om at hjælpe og inspirere til at stille relevante sikkerhedskrav ved udbud og indgåelse af it-kontrakter med leverandører. Kravene bygger på sikkerhedsforanstaltningerne i ISO 27001 anneks A (ISO 27002) og CIS kontroller (Critical Security Controls). Sidstnævnte er en række konkrete tiltag med fokus på operationel (teknisk) it-sikkerhed. Anvendelsen af kataloget forudsætter, at brugeren udvælger krav på baggrund af risikovurderinger, der bør understøtte ledelsens til- og fravalg af sikkerhedsmæssige tiltag. Kravene i opslagsværket er formuleret generisk, og kravene skal derfor tilpasses den konkrete kontraktuelle kontekst. Eksempelvis skal begrebsanvendelsen afstemmes med kontraktens definitioner. Der er desuden ikke tale om en udtømmende liste af krav, og der kan derfor være behov for at stille yderligere krav, der ikke fremgår af opslagsværket.

Hent Digitaliseringsstyrelsens opslagsværk om sikkerhedskrav 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.

Særlige kontraktbestemmelser ved samfundskritiske it-systemer

Ved samfundskritiske it-systemer skal myndigheder forholde sig til en række kontraktbestemmelser, som er udvalgt, fordi de særligt understøtter informationssikkerhed i relation til outsourcede it-systemer. Statslige myndigheder skal forholde sig til bestemmelserne i kataloget, før de indgår kontrakt om drift af samfundskritiske it-systemer. Nogle bestemmelser kan fravælges, hvis særlige forhold gør sig gældende. Altså skal kataloget følges efter følg-eller-forklar-princippet. Kataloget findes nedenfor. Vurderingen af it-systemers kritikalitet skal foretages af myndigheden selv. Definitioner på samfundskritiske it-systemer findes i ”Vejledning til model for porteføljestyring af statslige it-systemer” (se oes.dk), som myndigheder kan benytte i deres vurdering.

Katalog over kontraktbestemmelser for samfundskritiske it-systemer.  

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

Case: Differentierede kravkataloger i Rigspolitiet

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.

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.