De typiske fejl i et ISO 27001-projekt

ISO 27001 fejler sjældent, fordi folk ikke vil sikkerhed — den fejler, fordi projektet bliver for stort, for tungt og for løst forankret til at kunne leve i en travl forretning.

I denne artikel får du et praktisk overblik over de klassiske fejl i ISO 27001-arbejdet: for bredt scope, dokumentation der kollapser under sin egen vægt, og manglende ledelsesforankring. Du får også konkrete greb til at afgrænse scope, gøre dokumentationen lean og skabe en styringsmodel, der faktisk kan driftes.

Undervejs svarer jeg på typiske spørgsmål som: Hvad er ISO 27001, hvorfor betyder det noget, hvordan kommer man godt i gang, hvad koster det typisk i tid og penge, og hvilke best practices kan reducere risikoen for forsinkelser og “papir-ISMS”.

Hvad ISO 27001 er, og hvorfor det betyder noget

ISO 27001 er en international standard for etablering, implementering og løbende forbedring af et informationssikkerhedsledelsessystem (ISMS). Kort sagt: en ramme til at styre risici, kontroller og processer, så sikkerhed bliver en del af driften og ikke et engangsprojekt.

Standarden betyder noget, fordi den tvinger organisationen til at kunne forklare, hvilke aktiver man beskytter, hvilke trusler man prioriterer, og hvordan man dokumenterer, at kontrollerne virker. Det er relevant både for compliance (kundekrav, udbud, regulatoriske krav) og forretningsrobusthed (mindre nedetid, færre hændelser, bedre beslutninger).

Mini-konklusion: ISO 27001 er ikke “mere dokumentation” — det er en styringsmodel, hvor dokumentation kun har værdi, hvis den understøtter beslutninger og drift.

Fejl 1: For bredt scope — når “alt” bliver projektets fjende

Den mest almindelige måde at få ISO 27001 til at trække ud på er at starte med et scope, der omfatter hele organisationen, alle lokationer, alle systemer og alle leverandører på én gang. Det lyder ambitiøst, men det giver typisk tre problemer: for mange interessenter, for mange afhængigheder og for mange gråzoner.

Typiske symptomer på for bredt scope

• Ingen kan forklare, præcis hvad der er “inde” og “ude” af ISMS’et.
• Risikovurderingen ender som en liste med 100+ aktiver uden prioritering.
• Kontroller bliver generiske, fordi de skal passe til “alle” miljøer.
• Projektet går i stå i grænsedragning mellem IT, produkt, drift og forretning.
• Audit-forberedelse bliver en jagt på beviser på tværs af siloer.

Sådan afgrænser du scope uden at miste troværdighed

Et godt scope er ofte produkt- eller serviceorienteret: “Levering og drift af X-platformen inkl. tilhørende supportprocesser” fremfor “hele virksomheden”. I praksis ser jeg ofte, at et første scope på 20–40% af organisationen giver et realistisk gennemløb, mens resten kan fases ind over 6–18 måneder.

Brug disse tommelfingerregler:

1. Start der, hvor kundekravene er tydeligst (fx en SaaS-service eller en managed service).
2. Vælg et område med overskuelige systemgrænser og kendte dataflows.
3. Undgå at scope “samler alt op” via uklare formuleringer som “alle relaterede processer”.
4. Definér tydeligt interfaces til det, der er udenfor (fx fælles HR, finance eller facility) og beskriv, hvordan de styres.
5. Hold scope stabilt i implementeringsfasen; ændringer er ofte dyrere end man tror.

Mini-konklusion: Et snævrere scope er ikke en genvej — det er en måde at skabe et ISMS, der kan bevises, driftes og udvides kontrolleret.

Fejl 2: Tung dokumentation — når ISMS bliver et bibliotek, ingen bruger

ISO 27001 kræver dokumenteret information, men den kræver ikke en roman. Alligevel ender mange med 40–80 dokumenter, overlappende politikker og procedurer, og skabeloner der bliver udfyldt “for auditens skyld”. Resultatet er lav efterlevelse og høj vedligeholdelsesbyrde.

Hvorfor tung dokumentation opstår

Typisk skyldes det en kombination af skabelon-oversvømning, frygt for at “mangle noget til audit”, og et misforstået lighedstegn mellem compliance og papir. Jeg har set organisationer, hvor en ændring i én proces (fx onboarding) krævede opdatering af fem dokumenter, fordi de beskrev det samme med små variationer. Det er en opskrift på afvigelser.

Lean dokumentation: Skriv for drift, ikke for reolen

En praktisk tilgang er at skelne mellem “styrende” og “operativ” dokumentation. Styrende dokumentation er kort og stabil (politik, principper, roller, risikometode). Operativ dokumentation er tæt på arbejdet (runbooks, playbooks, tickets, pipeline-kontroller) og må gerne ligge i værktøjer fremfor PDF’er.

Gode greb, der ofte reducerer dokumentmængden 30–50% uden at miste kontrol:

• Saml beslægtede emner i én sikkerhedspolitik med klare bilag fremfor mange enkeltpolitikker.
• Brug “minimum viable procedure”: formål, trigger, ansvarlig, trin, evidens.
• Genbrug eksisterende artefakter: change logs, IAM-rapporter, backup-jobs, incident tickets.
• Lav én samlet “ISMS-kalender” for tilbagevendende aktiviteter (review, tests, træning).
• Fjern dobbeltbeskrivelser og peg i stedet på system-of-record (fx HR-system for roller).

Mini-konklusion: Hvis dokumentationen ikke kan forstås og anvendes af dem, der udfører arbejdet, skaber den afvigelser i stedet for sikkerhed.

Fejl 3: Manglende ledelsesforankring — når sikkerhed bliver et sideprojekt

ISO 27001 er et ledelsessystem. Det betyder, at ledelsen skal sætte retning, prioritere ressourcer og følge op. Når det ikke sker, får du et ISMS, der afhænger af ildsjæle og kollapser ved første travle kvartal.

Sådan ser svag ledelsesforankring ud i praksis

De klassiske tegn: risici accepteres uden begrundelse, beslutninger udskydes, og “security” bliver bedt om at løse problemer uden mandat. Jeg har set audits, hvor management review var en kalenderinvitation uden deltagelse, og hvor KPI’er var “antal dokumenter opdateret” i stedet for effektmål som patch lead time eller MFA-dækning.

Det ledelsen faktisk skal levere

Ledelsesforankring bliver konkret, når tre ting er på plads: beslutningskraft, prioritering og opfølgning. Et praktisk minimum er:

• En tydelig informationssikkerhedspolitik med mål, der giver mening for forretningen.
• En risikoholdning: hvad accepterer vi, og hvad accepterer vi ikke?
• Ressourcer: tid til kontroltest, træning, og forbedringer.
• Et fast forum (fx kvartalsvist) til management review med beslutningslog.
• En enkel rapportering: 6–10 metrics, der kan handles på.

Mini-konklusion: Uden ledelsens løbende beslutninger bliver ISO 27001 et dokumentprojekt — og audits bliver en årlig brandøvelse.

Fejl 4: Risikovurdering som excel-ritual i stedet for beslutningsværktøj

Risikovurderingen er motoren i ISO 27001, men mange gør den til et “en gang om året”-regneark, der ikke påvirker prioriteringer. Det sker især, når man scorer alt ens, eller når man ikke kobler risici til konkrete forbedringsopgaver.

Gør risikovurderingen operationel ved at:

1. Knytte risici til services og dataflows (ikke kun til teknologier).
2. Beskrive scenarier konkret: “Phishing → kompromitteret konto → adgang til kundedata”.
3. Koble hver top-risiko til 1–3 konkrete kontroller og en ansvarlig.
4. Definere “evidens”: hvad viser, at kontrollen virker (logs, rapporter, testresultater)?
5. Gennemgå top-risici løbende ved ændringer, ikke kun ved årsskiftet.

En nyttig sammenligning: En risikovurdering uden opfølgningsopgaver er som en brandøvelse uden flugtveje. Du ved noget kan gå galt, men du har ikke gjort det lettere at handle.

Mini-konklusion: Risikovurderingen skal ende i prioriterede handlinger, ellers bliver Annex A-kontrollerne tilfældige og svære at forsvare i audit.

Fejl 5: Annex A som tjekliste — “vi implementerer alt” eller “vi fravælger det meste”

Annex A (kontrolkataloget) misforstås ofte. Nogle prøver at implementere alt “for en sikkerheds skyld”. Andre fravælger mange kontroller uden at kunne forklare hvorfor. Begge dele skaber problemer, fordi audit handler om sammenhæng: scope → risici → valgte kontroller → evidens.

En sund praksis er at udarbejde en Statement of Applicability (SoA), der er kort, ærlig og sporbar. Hver kontrol bør have en af tre statusser: implementeret, planlagt eller ikke relevant — og altid med en begrundelse, der peger tilbage til risici og scope.

Midt i arbejdet kan det være hjælpsomt at sammenligne jeres erfaringer med typiske fejl i ISO 27001-projekt for at fange mønstre tidligt, før de bliver dyre at rette.

Mini-konklusion: Annex A er ikke et katalog over “ting man bør have” — det er et sæt kontroller, der skal være logisk afledt af jeres risici og kontekst.

Hvad ISO 27001 typisk koster — og hvad der driver prisen

Spørgsmålet “hvad koster ISO 27001?” kan ikke besvares med ét tal, men man kan være konkret om cost drivers. I danske SMV’er og scaleups ser jeg typisk, at den største omkostning er intern tid (processer, evidens, forbedringer) snarere end selve certificeringsaudit.

De vigtigste drivere er:

• Scope-størrelse (antal teams, systemer, lokationer, leverandører).
• Modenhed (har I allerede change management, logging, adgangsstyring, asset management?).
• Krav til evidens (fx kundekrav om hyppige tests, DR-øvelser, supplier reviews).
• Teknisk gæld (legacy, uensartede miljøer, manglende central IAM).
• Hvor meget der skal bygges op fra bunden (politikker, processer, awareness, målinger).

Som grov sammenligning: Hvis scope er velafgrænset, og grundprocesser findes, kan et forløb i praksis handle om at “stramme skruerne” og dokumentere effektivitet. Hvis scope er bredt og processer mangler, ender det mere som et transformationsprojekt med sikkerhed som drivkraft.

Mini-konklusion: Den billigste ISO 27001-vej er sjældent “hurtigst muligt” — det er “rigtigt første gang” med et scope og en dokumentation, der kan vedligeholdes.

Bedste praksis: En enkel plan, der reducerer risikoen for klassiske fejl

Hvis du vil undgå scope-creep, dokumentationsbyrde og svag forankring, så tænk ISO 27001 som et styringssystem, der skal kunne køre hver måned — ikke som en milepæl til en auditdato.

En praktisk 8-trins implementering (som kan skaleres)

1. Afklar formål og kundekrav: hvorfor certificering, og til hvilke services?
2. Fastlæg scope og grænseflader (inkl. outsourcings- og leverandørrelationer).
3. Definér risikometode og gennemfør en første risikovurdering med top-10 fokus.
4. Lav SoA med klare begrundelser og prioriter 5–10 kontroller til første bølge.
5. Byg governance: roller, møder, beslutningslog, ISMS-kalender.
6. Gør dokumentation lean og placer den tæt på arbejdet (værktøjer, tickets, pipelines).
7. Indsaml evidens løbende: logging, access reviews, change records, tests.
8. Kør interne audits og management review som “reelle checks” og ikke formaliteter.

Mål det, der betyder noget

Vælg metrics, der kan styres og forklares. Eksempler, der ofte giver mening:

• Andel brugere med MFA og stærk adgangspolitik.
• Patch lead time for kritiske sårbarheder.
• Gennemførte access reviews til tiden.
• Antal sikkerhedshændelser med root cause og corrective actions lukket.
• Restore-test succesrate og tid til gendannelse på kritiske systemer.

Mini-konklusion: En enkel plan med få, stærke styringsgreb slår et “alt på én gang”-projekt — især når hverdagen presser.

Når du opdager problemet sent: Sådan retter du kursen uden at starte forfra

Mange opdager først, at scope er for bredt, eller at dokumentationen er for tung, når audit nærmer sig. Det er sjældent nødvendigt at “kaste alt ud”. Ofte kan du redde forløbet ved at skære til og skabe sporbarhed.

Tre konkrete redningsgreb, jeg har set virke i praksis:

• Frys scope og lav en tydelig liste over “out of scope”-afhængigheder med ejere og controls på grænsefladen.
• Skær dokumentationen ned til de dokumenter, der styrer adfærd, og flyt resten til operationelle artefakter (tickets, konfigurationsstandarder, rapporter).
• Gennemfør et skarpt management review med beslutninger: accepter/mitigér/planlæg — og få det ned i en handlingsplan med deadlines.

Hvis du kan dokumentere, at du har kontrol over dine top-risici og kan vise stabil drift (evidens), er det ofte mere værd end at have “alle dokumenter på plads”.

Mini-konklusion: Kurskorrektion handler om at gøre ISMS’et beviseligt og styrbart — ikke om at producere mere materiale.