Intro:
Din Statement of Applicability (SoA) er et central del af at dokumentere dit ISMS. En SoA indeholder en liste med sikkerhedsforanstaltninger, som en organisation enten til- eller fravælger i arbejdet med informationssikkerhed.
Hvornår giver det mening at fravælge kontroller?
Du kan fravælge kontroller, hvis de ikke er relevante for jeres drift eller services. Det er vigtigt, at du dokumenterer en beslutning for hvert fravalg.
Bemærk: Nogle kontroller vil stort set altid vil være relevante, f.eks. ”Adgangsrettigheder” og ”Backup af information”, mens andre vil afhænge af din organisation og dens ydelser/produkter
Sådan kommer du i gang:
- Hvis I ikke allerede har aktiveret et framework kan dette gøres under Drift og kontrol > Kontroller. Læs mere om hvordan du aktiverer ISMS kontroller her
- For at fravælge en kontrol, og dermed starte jeres SoA, vælges Arkivér som fravalgt kontrol ud fra den valgte kontrol.
Tip: Hvis du benytter NIS2- eller DORA-frameworks, er kontrollerne minimumskrav og bør derfor som udgangspunkt ikke arkiveres. Dog giver det mening at fravælge de kontroller, som åbenlyst ikke passer til forretningen. Eksempelvis kan "Sikker programmering" fjernes som kontrol, hvis man ikke laver programmering.
Udarbejd din SoA
Nedenfor finder du en række ISO 27001- og ISAE 3402-kontroller, som i praksis ofte kan vurderes som ikke relevante – afhængigt af jeres organisations kontekst.
Listen er ikke udtømmende, men giver et overblik over de kontroller, som typisk kan fravælges i SoA’en, når de ikke har betydning for organisationens informationssikkerhed.
Bemærk: Hver fravalg bør altid baseres på en konkret vurdering og dokumenteres med en klar begrundelse.
| Kontrol nr. | Titel | Typisk grund til fravalg |
|---|---|---|
| 5.32 | Uafhængig vurdering af informationssikkerhed | Hvis organisationen ikke har besluttet at få foretaget ekstern/uafhængig vurdering af informationssikkerheden |
| 7.9 | Sikring af kabler | Hvis organisationen ikke har ansvar for fysisk netværksinfrastruktur |
| 8.4 | Adgang til kildekode | Hvis der ikke er intern kodebase eller adgang til kildekode |
| 8.9 | Håndtering af konfigurationer | Hvis I ikke selv konfigurerer systemer, men bruger standard SaaS-løsninger |
| 8.24 | Brug af kryptografi* | Hvis al kryptering varetages fuldt ud af leverandører, uden at I selv implementerer det |
| 8.25 | Sikker udviklingslivscyklus | Hvis organisationen ikke udvikler software eller systemer internt |
| 8.26 | Krav til applikationssikkerhed | Hvis der ikke udvikles, tilpasses eller konfigureres software/applikationer |
| 8.27 |
Sikker systemarkitektur og udviklingsprincipper |
Hvis organisationen ikke udvikler egne informationssystemer, og ikke har ansvar for tilpasning eller systemdesign. |
| 8.28 | Sikker programmering | Hvis der ikke skrives kode i organisationen (fx ingen intern softwareudvikling) |
* Husk dog, at Datatilsynet kræver kryptering af e-mails, der indeholder følsomme eller andre fortrolige personoplysninger