Fra efterlevelse til robusthed: Sådan lukker informationssikkerhedschefer styringskløften

Kl. 03-alarmen: Et styringssvigt forklædt som en sikkerhedshændelse
Maria, informationssikkerhedschef i en hurtigt voksende fintech-virksomhed, blev brat vækket af en P1-alarm. En produktionsdatabase, der angiveligt var isoleret, kommunikerede med en ukendt ekstern IP-adresse. Hendes SOC-team var allerede i gang og sporede forbindelsen tilbage til en fejlkonfigureret cloud-bucket til objektlagring, som var oprettet af et marketinganalyseteam, der testede et nyt værktøj til kundesegmentering. Den umiddelbare skade blev inddæmmet, men efterhændelsesgennemgangen afslørede et langt mere alvorligt problem, som hverken handlede om firewalls eller malware.
Marketingchefen, der havde bestilt værktøjet, var ikke underlagt noget formelt sikkerhedstilsyn. DevOps-ingeniøren, der oprettede miljøet, sprang de normale sikkerhedskontroller over for at overholde en stram deadline. Dataene i bucketen var ganske vist anonymiserede, men stadig følsomme nok til at udløse kontraktlige underretningsklausuler over for flere nøglekunder.
Rodårsagen var ikke en teknisk sårbarhed. Det var et alvorligt styringssvigt. Maria havde politikker, værktøjer og et dygtigt team. Det, hun manglede, var en styringsramme, der var levende, håndhævet og forstået uden for sikkerhedsafdelingen. Hendes virksomhed var efterlevende på papiret, dens ISO/IEC 27001:2022-certifikat hang stadig flot på væggen, men i praksis var virksomheden ikke robust.
Det er denne kritiske kløft, mange organisationer og deres informationssikkerhedschefer snubler over. De forveksler styringens artefakter, politikkerne og tjeklisterne, med selve styringen. Denne artikel gennemgår, hvor denne tankegang går galt, og giver en konkret køreplan for at omsætte efterlevelse på papiret til vedvarende forretningsmæssig kontrol ved hjælp af Clarysecs integrerede værktøjssæt.
Ud over ringbindet: Styring som handling
Styring er alt for længe blevet behandlet som et substantiv: en statisk samling dokumenter lagret på en server. Reel informationssikkerhedsstyring er derimod en handling. Det er det løbende sæt aktiviteter, som ledelsen udfører for at lede, overvåge og understøtte sikkerhed som en central forretningsfunktion. Det handler om at skabe et system, hvor alle, fra bestyrelseslokalet til udviklingsteamet, forstår deres rolle i beskyttelsen af organisationens informationsaktiver.
Rammeværker fra ISO/IEC 27001:2022 til NIS2 begynder med denne sandhed: Styring er en ledelsesfunktion, ikke en teknisk funktion. Ifølge ISO/IEC 27014:2020 skal øverste ledelse etablere en informationssikkerhedsstrategi, der er tilpasset organisationens mål. Strategien skal sikre, at sikkerhedskrav opfylder både interne og eksterne behov, herunder retlige, regulatoriske og kontraktlige forpligtelser. For at bekræfte dette skal ledelsen iværksætte uafhængige revisioner, fremme en kultur, der aktivt understøtter sikkerhed, og sikre, at mål, roller og ressourcer er koordinerede.
Problemet er, at denne “tone fra toppen” ofte ikke omsættes til handling på det operationelle niveau. Det er her, den mest kritiske og ofte misforståede kontrol kommer i spil: ledelsesansvar.
Den kaskaderende effekt: Hvorfor sikkerhed ikke kan stoppe hos informationssikkerhedschefen
Den største enkeltstående fejlkilde i ethvert ledelsessystem for informationssikkerhed (ISMS) er antagelsen om, at informationssikkerhedschefen alene er ansvarlig for sikkerheden. I praksis er informationssikkerhedschefen dirigenten, men lederne af hver forretningsenhed er musikerne. Hvis de ikke spiller deres del, bliver resultatet støj, ikke harmoni.
Det er præcis det, ISO/IEC 27001:2022 adresserer i kontrol 5.4, “Ledelsens ansvar”. Denne kontrol kræver, at ansvar for informationssikkerhed tildeles og håndhæves i hele organisationen. Som vores Zenith Blueprint: En revisors 30-trins køreplan fremhæver i trin 23, handler denne kontrol om at sikre, at sikkerhedsledelse kaskaderes gennem alle lag i organisationen.
“I sidste ende understreger Control 5.4, at sikkerhedsledelse ikke stopper hos informationssikkerhedschefen. Den skal kaskaderes gennem alle lag af den operationelle ledelse, fordi succes eller svigt i dit ISMS ofte ikke afhænger af politikker eller værktøjer, men af om ledere aktivt fremmer sikkerhed inden for deres egne ansvarsområder.” Zenith Blueprint
I Marias tilfælde så marketingchefen sikkerhed som en forhindring, ikke som et fælles ansvar. DevOps-ingeniøren så en deadline, ikke en omsorgs- og kontrolforpligtelse. En levende styringsramme ville have indlejret sikkerhedskontroller i projektopstarten og i resultatmålene for DevOps-teamet. Det ændrer styring fra en efterlevelsesbyrde til et værktøj til at undgå alvorlige hændelser.
Fra teori til praksis: Opbygning af styring med handlingsrettede politikker
En politik på en hylde er et artefakt; en politik integreret i den daglige drift er en kontrol. For at operationalisere styring har organisationer brug for en entydig definition af ansvar. Vores Governance Roles & Responsibilities Policy er udformet til netop dette formål. Et af dens centrale mål er:
“At opretholde en styringsmodel, der håndhæver funktionsadskillelse, eliminerer interessekonflikter og muliggør eskalering af uløste sikkerhedsforhold.” Politik for styringsroller og ansvarsområder
Denne formulering omsætter et overordnet princip til et konkret, revisionsbart krav. Den etablerer en ramme for lagdelt ansvarlighed, hvor hvert ledelsesniveau er registreret som ansvarligt for sin del af sikkerhedsprogrammet. For mindre organisationer forenkler Governance Roles & Responsibilities Policy - SME dette og fastslår direkte i klausul 4.3.3, at hver medarbejder “skal straks rapportere hændelser og efterlevelsesforhold til direktøren”. Denne klarhed fjerner tvetydighed og giver alle mulighed for at handle.
Lad os vende tilbage til Marias hændelse og se, hvordan hun kunne bruge Clarysecs værktøjssæt til at genopbygge sin tilgang til styring og omsætte et reaktivt svigt til et proaktivt, robust system.
Politikken som fundament: Først ville hun implementere Politik for styringsroller og ansvarsområder. I samarbejde med HR ville hun integrere konkrete sikkerhedsansvar i jobbeskrivelserne for alle ledere, fra marketing til økonomi. Det gør sikkerhed til en formel del af deres rolle, ikke en eftertanke.
Definition af “hvordan”: Dernæst ville hun bruge politikken til at etablere en klar proces. Klausul 7.2.2 i politikken fastslår: “Styringsrelaterede risici skal gennemgås af ISMS-styregruppen og valideres under interne revisioner.” Det skaber et formelt forum, hvor marketingchefens nye projekt ville være blevet gennemgået, før et cloudmiljø blev oprettet, og hvor den oprindelige fejlkonfiguration dermed kunne være undgået.
Udnyttelse af intelligens på tværs af efterlevelseskrav: For at forstå det fulde omfang af sin nye styringsmodel ville Maria bruge Zenith Controls: Guiden til efterlevelse på tværs af rammeværker. Denne ressource viser, hvordan “Ledelsens ansvar” (ISO 5.4) ikke er en isoleret opgave, men et centralt knudepunkt, der forbinder andre kritiske kontroller. Den viser f.eks. den direkte sammenhæng mellem 5.4 og 5.8 (“Informationssikkerhed i projektledelse”) og sikrer dermed, at ledelsen udøver det nødvendige tilsyn for at indlejre sikkerhed i alle nye initiativer.
Denne proaktive tilgang flytter styring fra reaktiv analyse efter hændelser til en funktion, der understøtter forretningen. Den sikrer, at når en leder vil lancere et nyt værktøj, er den første tanke ikke “Hvordan får jeg dette forbi sikkerhed?”, men “Hvem i sikkerhedsteamet skal jeg samarbejde med?”
Revisoren kommer: Sådan dokumenterer du, at din styring er reel
En erfaren revisor er trænet i at lede efter bevis for implementering, et begreb som Zenith Blueprint kalder sammenhængen mellem politik og “virkelighed”. Når en revisor vurderer din styringsramme, læser vedkommende ikke blot dokumenter; vedkommende tester organisationens muskelhukommelse. Revisoren leder efter revisionsbevis for, at styringen er levende, aktiv og responsiv.
Forskellige revisorer vil undersøge din styringsramme fra forskellige vinkler. Sådan ville de teste Marias nye, robuste styringsmodel:
ISO/IEC 27001:2022-revisoren: Denne revisor går direkte til beviset for ledelsens forpligtelse, som kræves i klausul 5.1. Revisoren vil bede om referater fra ledelsens gennemgang (klausul 9.3). Revisoren vil se efter dagsordenspunkter, hvor sikkerhedens resultater blev drøftet, ressourcer blev allokeret, og beslutninger blev truffet på grundlag af risikovurderinger. Revisoren vil se, at ledelsen ikke blot modtager rapporter, men aktivt styrer ISMS’et.
COBIT 2019-revisoren: En COBIT-revisor tænker i organisatoriske mål. Vedkommende vil fokusere på styringsmål som EDM03 (“Ensured Risk Optimization”). Revisoren vil bede om at se de risikorapporter, der er præsenteret for bestyrelsen, og vil vide, om ledelsen følger centrale sikkerhedsindikatorer og iværksætter korrigerende handlinger, når indikatorerne udvikler sig negativt. For denne revisor handler styring om at sikre, at sikkerhed muliggør og beskytter forretningsværdi.
ISACA-revisoren: Styret af rammeværker som ITAF har denne revisor skarpt fokus på “tone fra toppen”. Revisoren vil gennemføre interviews med øverste ledelse for at vurdere deres forståelse og forpligtelse. Et langsomt eller afvisende svar fra ledelsen på en tidligere revisionskonstatering er et alvorligt advarselstegn, der indikerer en svag styringskultur.
NIS2- eller DORA-tilsynsmyndigheden: Med reguleringer som NIS2 og DORA er indsatsen højere. Disse rammeværker pålægger ledelsesorganer direkte, personligt ansvar for svigt inden for cybersikkerhed. En revisor fra en kompetent myndighed vil kræve revisionsbevis for, at bestyrelsen har godkendt rammen for styring af cybersikkerhedsrisici, ført tilsyn med dens implementering og modtaget specialiseret træning. De leder efter dokumentation for, at ledelsen ikke blot er orienteret, men aktivt involveret og ansvarlig.
For at opfylde disse forskellige revisionstilgange skal du fremlægge mere end blot politikker. Du har brug for en portefølje af revisionsbevis.
| Fokusområde for revision | Krævet revisionsbevis |
|---|---|
| Engagement fra øverste ledelse | Referater fra ledelsens gennemgang, godkendte budgetter, præsentationer for bestyrelsen og strategisk kommunikation. |
| Gennemgang af effektivitet | Handlingslogfiler fra ledelsesbeslutninger, sporede risikoreducerende handlinger fra risikovurderinger. |
| Ansvarlighed og respons | RACI-matricer, jobbeskrivelser med sikkerhedsansvar, hændelsesrapporter, der viser eskalering til ledelsen. |
| Formel tildeling | Underskrevne mandater for sikkerhedsudvalg, formelle rollebeskrivelser for risikoejere, årlige attestationer fra afdelingsledere. |
Hvis dit bevismateriale kun består af politik-PDF’er og ingen operationelle logfiler, vil du ikke bestå revisionen. Guiden Zenith Controls hjælper dig med at sammensætte den rigtige portefølje, så du dokumenterer revisionsbevis, ikke kun intentioner.
Feedbacksløjfen: Fra hændelser til robusthed
I sidste ende er det stærkeste bevis på en robust styringsramme, hvordan organisationen reagerer på svigt. Reel robusthed betyder at lære, tilpasse sig og handle. Som Zenith Blueprint anfører i gennemgangen af kontrol 5.24 (“Planlægning og forberedelse af styring af informationssikkerhedshændelser”):
“Det, der kendetegner en sikker organisation, er ikke fraværet af hændelser, men beredskabet til at håndtere dem, når de opstår … Denne kontrol handler om forbedring, ikke kun lukning. Revisorer vil spørge: ‘Hvad lærte I af jeres seneste hændelse?’ De forventer at se rodårsagsanalyse, opsamlede læringspunkter og vigtigst af alt bevismateriale for, at noget blev ændret som følge heraf.”
I Marias tilfælde var “det, der blev ændret”, ikke blot en firewallregel. Det var implementeringen af en styringsproces, der krævede ledelsesgodkendelse af nye projekter, en klar RACI-matrix for cloudimplementeringer og obligatorisk sikkerhedstræning for marketingteamet. Hendes evne til at dokumentere denne læringssløjfe ville omsætte en potentiel større afvigelse til revisionsbevis for et modent ISMS under forbedring.
Det er her, styring beviser sin værdi. Et svigt er ikke længere blot et teknisk problem, der skal løses, men en organisatorisk læring, der skal opsamles og integreres. Som Politik for styringsroller og ansvarsområder fastslår i afsnit 9.1.1.4, bliver “væsentlige revisionskonstateringer eller hændelser, der involverer styringssvigt” ikke begravet; de gennemgås, eskaleres og håndteres.
Sådan får du styring til at holde: Ansvarlighedens rolle
Selv med de bedste politikker og ledelsesmæssig opbakning kan styring svigte, hvis der ikke er konsekvenser ved manglende efterlevelse. En reelt robust ramme skal understøttes af en fair, ensartet og klart kommunikeret disciplinær proces. Det er fokus for ISO/IEC 27001:2022 kontrol 6.4, “Disciplinær proces”.
Denne kontrol sikrer, at reglerne i ISMS’et ikke er valgfrie. Den giver den håndhævelsesmekanisme, der dokumenterer ledelsens forpligtelse til sikkerhed. Som beskrevet i Zenith Controls er denne proces en kritisk risikobehandling for insidertrusler og uagtsomhed. Den fungerer sammen med andre kontroller: overvågningsaktiviteter (8.16) kan identificere et brud på politikken, mens den disciplinære proces (6.4) fastlægger den formelle respons.
“Disciplinære foranstaltninger er mere juridisk forsvarlige, når medarbejdere er tilstrækkeligt trænet og gjort bekendt med deres ansvar. Control 6.4 bygger på 6.3 (Bevidsthed om informationssikkerhed, uddannelse og træning) for at sikre, at personale ikke kan påberåbe sig uvidenhed om politikker, de har overtrådt.”
En revisor vil kontrollere, at denne proces anvendes konsekvent på alle niveauer, så en topleder, der overtræder clean desk-politikken, er underlagt samme proces som en praktikant. Det er det sidste led i kæden, der gør styring fra vejledning til en standard, der kan håndhæves.
Det samlede efterlevelseskort: Ét samlet overblik over styring
Presset fra moderne styring er, at den aldrig befinder sig i ét enkelt rammeværk. Reguleringer som NIS2 og DORA har løftet ledelsesansvar fra bedste praksis til et retligt krav med personligt ansvar. En robust informationssikkerhedschef skal kunne dokumentere styring på en måde, der opfylder flere revisorers krav samtidigt.
Denne samlede tabel, baseret på kortlægninger i Zenith Controls, viser, hvordan princippet om ledelsesansvar er et universelt krav på tværs af de centrale rammeværker.
| Rammeværk/standard | Relevant klausul/kontrol | Hvordan det kortlægger til ledelsesansvar på øverste niveau (ISO 5.4) |
|---|---|---|
| ISO/IEC 27001:2022 | Klausuler 5.1, 5.2, 9.3 | Kræver aktiv ledelse, integration af ISMS’et i forretningsprocesser og regelmæssig ledelsens gennemgang. |
| EU NIS2 | Article 21(1) | Ledelsesorganer skal godkende og føre tilsyn med praksis for styring af cybersikkerhedsrisici med personligt ansvar for svigt. |
| EU DORA | Article 5(2) | Ledelsesorganet har det ultimative ansvar for enhedens styringsramme for IKT-risici og digitale operationelle robusthed. |
| EU GDPR | Articles 5(2), 24(1) | Ansvarlighedsprincippet kræver, at dataansvarlige (øverste ledelse) dokumenterer efterlevelse og implementerer passende foranstaltninger. |
| NIST SP 800-53 | PM-1, PM-9 | Ledelsen skal etablere planen for sikkerhedsprogrammet og oprette en risikostyringsfunktion på ledelsesniveau til samlet tilsyn. |
| COBIT 2019 | EDM03 | Bestyrelsen og direktionen skal evaluere, lede og overvåge sikkerhedsinitiativer for at sikre tilpasning til forretningsmål. |
Konklusionen er klar: Alle revisorer, uanset rammeværk, samles om samme krav: “Vis mig styringen i praksis.”
Konklusion: Fra afkrydsningsfelt til kompas
Den ubehagelige sandhed er, at “efterlevende” organisationer rammes af sikkerhedsbrud hver dag. “Robuste” organisationer overlever og tilpasser sig. Robusthed kræver dyb integration af politik, teknologi og reelt ejerskab hos øverste ledelse. Det er ikke en parade af formularer, men en kultur, hvor sikkerhed og forretningsstrategi bevæger sig i takt.
Start med at stille de svære spørgsmål:
- Er vores sikkerhedsledelse synlig? Deltager ledere uden for sikkerhedsfunktionen aktivt i risikobeslutninger?
- Er ansvaret klart? Kan hver leder formulere sit konkrete ansvar for at beskytte information inden for sit område?
- Er styring integreret? Er sikkerhedshensyn indbygget i vores projektledelse, indkøb og HR-processer fra starten?
- Lærer vi af vores fejl? Når en hændelse opstår, udløser den så en gennemgang af vores styringsramme og ikke kun vores tekniske kontroller?
Forskellen på at overleve en hændelse eller fejle under regulatorisk kontrol afhænger af, hvor dybt styring er vævet ind i driften. Styring er det kompas, der leder organisationen gennem usikkerhed. I krisens øjeblik står kun reel styring mellem efterlevelse og katastrofe.
Næste skridt: Gør din robusthed målbar
- Brug Zenith Blueprint til at gennemføre et realitetstjek af ledelsens ansvarlighed og sikre, at sikkerhed har synlighed på tværs af forretningen.
- Implementér Clarysecs politikker som Politik for styringsroller og ansvarsområder som levende dokumenter, der driver træning, eskalering og korrigerende handlinger.
- Brug Zenith Controls til at sikre, at I er klar til revision på tværs af ISO/IEC 27001:2022, NIS2, DORA og flere andre rammeværker med konkrete kortlægninger og evidenspakker.
Klar til at udvikle din styring fra et afkrydsningsfelt til et kompas? Book en ISMS-gennemgang af styring med Clarysec, og få dit ledelsesteam reelt placeret bag rattet.
Referencer:
- Zenith Blueprint: En revisors 30-trins køreplan
- Zenith Controls: Guiden til efterlevelse på tværs af rammeværker
- Politik for styringsroller og ansvarsområder
- Politik for styringsroller og ansvarsområder - SMV
- ISO/IEC 27001:2022, ISO/IEC 27014:2020, ISO/IEC 27005:2022, DORA, NIS2, GDPR, NIST SP 800-53 Rev.5, COBIT 2019.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


