5 fejl at undgå under ISO 27001 implementering

Lær af virkelige fejl for at fremskynde din certificering

Hjem Blog Implementeringsguide

⚠️ Introduktion

ISO 27001-implementeringsfejl koster svenske virksomheder tid, penge og konkurrencefordel. Baseret på reelle implementeringer og revisionsiagttagelser er her de 5 mest almindelige – og mest skadelige – fejl, organisationer begår, og hvordan man undgår dem.

Dette er ikke teoretiske faldgruber. Det er fejl, vi gentagne gange har set koste organisationer måneders forsinkelse, titusindvis af euro i omgørelsesarbejde og mislykkede revisioner. Lær af andres smerte.

❌ Fejl #1: At definere scope for bredt

Problemet

Organisationer forsøger at certificere alt på første dag. »Vores scope er hele virksomheden« lyder omfattende. I virkeligheden er det en opskrift på fiasko. Bredt scope betyder:

  • Flere aktiver at inventere og klassificere
  • Flere risici at vurdere og håndtere
  • Flere kontroller at implementere og dokumentere
  • Flere revisionsdage (højere certificeringsomkostninger)
  • Længere implementeringstidslinje (6-12 måneder mod 3-4 måneder)

Reelt eksempel

En svensk SaaS-virksomhed med 50 medarbejdere satte indledningsvist scope til »alle virksomhedens operationer inkl. kontorfaciliteter, HR-systemer, udvikling, produktion og salg«. Dette betød:

  • Fysisk sikkerhed for 3 kontorplaceringer
  • Krav til HR-databeskyttelse
  • Sikkerhed i salgs-CRM (lav værdi, men høj indsats)
  • Udvikling og produktion (høj værdi, høj indsats)

Resultat: 8 måneder til implementering, €45.000 i samlet omkostning, udbrændt team.

Løsningen

Start med minimalt levedygtigt scope: Kernen af IT-drift direkte relateret til din primære servicelevering. For SaaS-virksomheder:

  • Produktionsinfrastruktur (AWS/Azure-miljøer)
  • Udviklingssystemer der direkte understøtter produktion
  • Kernestøttetjenester (autentificering, overvågning, backup)

Udelad indledningsvist:

  • Kontorfaciliteter (håndter separat eller udelad)
  • HR-systemer (medmindre I er en HR-tech-virksomhed)
  • Salgs-/markedsføringssystemer (lav risiko, høj dokumentationsbyrde)

Udvid senere: Tilføj scope under overvågningsrevisioner, når den indledende certificering er opnået, og I har driftserfaringer med ISMS.

Effekt: Samme virksomhed gensatte scope til »AWS-produktionsinfrastruktur og relaterede udviklingssystemer«. Implementering: 3 måneder, €28.000, certificering opnået ved første revisionsforsøg.

❌ Fejl #2: At skabe ulæselig dokumentation

Problemet

Organisationer skriver politikker TIL revisorer frem for TIL personalet. Resultatet: 200-siders politikdokumenter ingen læser, komplekse procedurer afkoblet fra virkeligheden og »hyldesoftware«, der kun eksisterer for certificeringens skyld.

Advarselstegn

  • Informationssikkerhedspolitikken fylder 50+ sider
  • Politikker refererer til andre politikker, der refererer til rammer, der refererer til standarder
  • Personalet kan ikke forklare politikkerne med egne ord
  • Procedurer er ikke opdateret siden certificeringen
  • Kontroller beskrevet i dokumentationen svarer ikke til den faktiske praksis

Løsningen

Skriv til praktikere, ikke til overholdelsesshow:

  • Hold politikkerne kortfattede: maks. 2-5 sider pr. politik
  • Brug et klart sprog: Hvis juniorudviklere ikke kan forstå det, er det for komplekst
  • Dokumenter hvad I GØR: Ikke hvad I ønsker I gjorde, eller hvad I tror I bør gøre
  • Integrer med arbejdsgange: Sikkerhedsprocedurer bør passe til eksisterende processer, ikke skabe parallelle overholdelsesspor
  • Brug eksempler: Vis hvad god praksis ser ud, og kræv det ikke blot

Eksempel – dårligt mod godt:

❌ Dårligt (Overholdelsesshow)

"Access to information assets shall be restricted to authorized personnel based on business need-to-know principles as determined by asset owners through formal authorization workflows documented in the access management system in accordance with the least privilege principle..."

✅ Godt (Praktisk vejledning)

"Access Control: Use AWS IAM with MFA required. Developers get read-only production access. Only SREs get write access. Review permissions quarterly. See AWS-Access-Playbook.md for step-by-step setup."

Reference: Se Hack23's offentlige ISMS for eksempler på kortfattede, praktiske politikker (2-5 sider hver).

❌ Fejl #3: At springe over korrekt risikovurdering

Problemet

Organisationer behandler risikovurdering som en afkrydsningsøvelse for at nå »det egentlige arbejde« med at implementere kontroller. Resultat: Implementering af kontroller, der ikke imødegår de reelle risici, overser kritiske trusler og spildes ressourcer.

Typiske genveje (alle forkerte)

  • »Vi implementerer blot alle 93 Bilag A-kontroller« – spild af ressourcer på irrelevante kontroller
  • »Lad os kopiere risici fra en skabelon« – generiske risici, ikke jeres risici
  • »Risikovurdering tager for lang tid« – så implementerer I de forkerte kontroller og fejler revisionen
  • »Vi kender vores risici uden formel vurdering« – ustated antagelser ≠ risikostyring

Løsningen

Invester 2-3 uger i korrekt risikovurdering:

  1. Aktivopgørelse (uge 1): Hvilke informationer og systemer er faktisk vigtige?
    • Informationsaktiver (kundedata, kildekode, legitimationsoplysninger, forretningsplaner)
    • Systemaktiver (produktionsservere, udviklingsmiljøer, CI/CD)
    • Afhængigheder (cloud-udbydere, SaaS-værktøjer, tredjeparts-API'er)
  2. Trusselidentifikation (uge 2): Hvad truer realistisk disse aktiver?
    • Eksterne trusler (ransomware, DDoS, databrud, forsyningskædeangreb)
    • Interne trusler (fejlkonfigurationer, menneskelige fejl, insidertrusler)
    • Miljømæssige (AWS-nedetid, datacenterproblemer)
  3. Risikobehandling (uge 3): Hvilke kontroller reducerer faktisk jeres risici?
    • Implementér ikke kontroller »fordi Bilag A siger det«
    • Implementér kontroller fordi de behandler identificerede risici
    • Acceptér nogle lave risici frem for at overkontrollere alt

Udbytte: Korrekt risikovurdering betyder implementering af 50-70 relevante kontroller frem for at tvinge alle 93 igennem. Sparer 20-40 timers implementeringstid og producerer en forsvarlig anvendelseserklæring.

❌ Fejl #4: Svag ledelsesopbakning

Problemet

ISO 27001 behandles som et IT-projekt, ikke som en forretningsinitiativ. Når deadlines nærmer sig, eller budgetter strammes, nedprioriteres ISMS-arbejdet. Teams udbrænder i kampen om ressourcer. Implementeringen går i stå.

Advarselstegn på svag opbakning

  • Sikkerhedschef tigger om budget/tid
  • ISMS-arbejde udføres »når der er tid« (dvs. aldrig)
  • Ledelsen springer ledelsesgennemgangsmøder over
  • Ingen konsekvenser når teams ignorerer sikkerhedsprocedurer
  • Certificeringsdeadline skrider gentagne gange

Løsningen

Præsentér ISO 27001 som omsætningsfremmende, ikke som en IT-afkrydsning:

  • Forretningsargumentfokus:
    • »Certificering låser op for €500K-enterprise-aftale« (ikke »vi bør være sikre«)
    • »Reducerer salgscyklus med 30%« (ikke »bedste praksis«)
    • »Krævet til offentlige sektorudbud« (ikke »overholdelse«)
  • Ledelsesmæssig sponsorering:
    • CEO eller C-niveau ejer offentligt certificeringsmålet
    • Regelmæssige opdateringer til bestyrelse/ledelsesteam
    • Beskyttet budget og tidslinje
    • Konsekvenser for manglende deltagelse
  • Synlig forpligtelse:
    • Ledelsen gennemfører sikkerhedstræning som de første
    • Ledere deltager i vigtige ISMS-møder
    • Sikkerhedsnøgletal i virksomhedens scorekort

Realitetstjek: Uden ledelsesopbakning tager ISO 27001-implementering 2 gange så lang tid og koster 1,5 gange mere på grund af konstante ressourcekampe og nedprioritering. Sikr forpligtelsen, eller start ikke.

❌ Fejl #5: At behandle certificeringen som målstregen

Problemet

Organisationer fejrer certificeringen og forsømmer derefter ISMS-vedligeholdelsen. Resultat: Forringede kontroller, mislykkede overvågningsrevisioner og suspension af certifikatet – og dermed spildes hele den indledende investering.

Forsømmelse efter certificering ser sådan ud

  • Politikker ikke opdateret i 18+ måneder
  • Risikovurdering ikke opdateret, når systemer ændres
  • Sikkerhedsbevidsthedstræning springes over
  • Interne revisioner gennemføres forhastet eller springes over
  • Ledelsesgennemgang bliver et gummistempelmøde
  • Nye kontroller implementeres uden ISMS-dokumentation

Løsningen

Planlæg løbende drift fra første dag:

  • Tildel løbende ansvarsområder:
    • ISMS-leder (5-10 timer/uge): koordinering, dokumentation
    • Kontrolejere: vedligehold beviser, rapporter problemer
    • Intern revisor: kvartalsvise kontroller
  • Planlæg tilbagevendende aktiviteter:
    • Kvartalsvist: Gennemgang af risikoregister, interne revisioner
    • Halvårligt: Politikgennemgange, kontrol af kontroleffektivitet
    • Årligt: Ledelsesgennemgang, sikkerhedsbevidsthedstræning, overvågningsrevision
  • Automatiser indsamling af beviser:
    • Automatiseret logindsamling (ikke manuelle skærmbilleder)
    • Planlagte sårbarhedsscanninger
    • Sporing af gennemførelse af træning
    • Adgangsgennemgangsrapporter
  • Integrer i forretningsprocessen:
    • Sikkerhedsgennemgang i projektplanlægning
    • ISMS-opdateringer i ændringsstyring
    • Risikovurdering for nye initiativer

Tidsinvestering: 2-4 timer/uge på vedligeholdelse af ISMS mod måneder med udbedring ved mislykket overvågningsrevision.

→ Se den fulde implementeringsvejledning for vedligeholdelsesstrategier efter certificering

✅ Vigtigste pointer

  1. Scope smart: Start smalt, udvid senere
  2. Skriv praktiske politikker: Til praktikere, ikke revisorer
  3. Invester i risikovurdering: Driver alt andet
  4. Sikr ledelsesopbakning: Præsenter som forretningsfremmende
  5. Planlæg vedligeholdelse: Certificering er starten, ikke slutningen

Undgå disse fejl: Få ekspertvejledning fra Hack23. Vi har begået disse fejl, så I ikke behøver.

📚 Relaterede ressourcer