Fra scanninger til revisionsbevis: ISO 27001:2022, NIS2, DORA

Klokken er 08:16 en mandag. En kritisk sårbarhed med mulighed for fjernudførelse af kode er netop dukket op på dashboardet for en internetvendt applikationsserver. Infrastrukturteamet oplyser, at leverandørens patch er tilgængelig. Den applikationsansvarlige advarer om, at serveren understøtter en indtægtskritisk kundearbejdsgang. Juridisk afdeling spørger, om udnyttelse kan udløse rapportering efter NIS2, DORA eller GDPR. CISO Maria åbner revisionskalenderen og ser det egentlige problem: ISO 27001:2022-overvågningsrevisionen starter i næste uge, en NIS2-parathedsgennemgang er allerede i gang, og en stor fintech-kunde har anmodet om DORA-bevismateriale.

Scanneren viser rødt. Sagstavlen viser aktivitet. Regnearket viser indsats. Men intet af det dokumenterer automatisk kontrol.

Det er dette hul, mange organisationer opdager for sent. Sårbarhedsscanning er ikke det samme som revisionsberedskab for sårbarhedsstyring. En scanning viser, at noget kan være galt. Revisionsbevis dokumenterer, at organisationen vidste, hvilke aktiver den havde, vurderede risikoen, tildelte ejerskab, handlede i overensstemmelse med politikken, styrede ændringen, dokumenterede undtagelser, verificerede resultatet og gennemgik udfaldet.

For ISO/IEC 27001:2022, NIS2 og DORA er denne beviskæde lige så vigtig som den tekniske rettelse. Scanneren starter forløbet. Aktivfortegnelsen, sårbarhedsregisteret, sagen, risikobeslutningen, ændringsregistreringen, patchloggen, valideringsbeviset, godkendelsen af undtagelsen og ledelsens gennemgang fuldender det.

Clarysecs tilgang er enkel: behandl ikke sårbarhedsstyring som et månedligt teknisk ritual. Behandl den som en styret arbejdsgang for revisionsbevis.

Hvorfor scanningsrapporter fejler som revisionsbevis

En sårbarhedsscanning er en teknisk observation på et bestemt tidspunkt. Den kan identificere en CVE, en manglende patch, et ikke-understøttet bibliotek, en eksponeret tjeneste eller en svag konfiguration. Det er nyttigt, men det er ufuldstændigt.

En auditor vil stille andre spørgsmål:

• Var det berørte aktiv omfattet af scope?
• Hvem ejer aktivet og forretningstjenesten?
• Blev sårbarheden vurderet ud fra eksponering, udnyttelighed, forretningsmæssig påvirkning og datafølsomhed?
• Blev afhjælpning gennemført inden for den definerede tidsramme?
• Hvis afhjælpning blev forsinket, hvem accepterede så restrisikoen?
• Blev patchen udrullet gennem kontrolleret ændringsstyring?
• Blev rettelsen verificeret ved genscanning eller teknisk validering?
• Blev bevismaterialet opbevaret og gennemgået af ledelsen?

En mappe med eksportfiler fra scanneren besvarer sjældent disse spørgsmål. Ved en ISO 27001:2022-revision tester auditoren, om ISMS’et fungerer som designet. Under NIS2 skal ledelsesorganer godkende og føre tilsyn med foranstaltninger til styring af cybersikkerhedsrisici. Under DORA skal finansielle enheder have et dokumenteret rammeværk for styring af IKT-risiko, en livscyklus for hændelser, robusthedstest og kontroller for IKT-tredjepartsrisici. Under GDPR er spørgsmålet, om passende tekniske og organisatoriske foranstaltninger beskyttede personoplysninger, og om ansvarlighed kan dokumenteres.

ISO/IEC 27001:2022, punkt 4.1 til 4.4, kræver, at organisationen forstår sin kontekst, interessenter, krav og ISMS-omfang. Sårbarheds- og patchstyring kan ikke designes isoleret. Den skal afspejle kundekontrakter, tilsynsmyndigheder, cloudafhængigheder, outsourcede IKT-tjenester, databeskyttelsesforpligtelser og kritiske tjenester.

ISO/IEC 27001:2022, punkt 6.1.1 til 6.1.3, kræver risikovurdering, risikobehandling, kontroludvælgelse, en Statement of Applicability og risikoejerens godkendelse af restrisiko. Det betyder, at bevismateriale for sårbarheder bør kobles til risikoregisteret, behandlingsplanen og SoA.

ISO/IEC 27005:2022 styrker denne model ved at anbefale, at organisationer konsoliderer krav fra Annex A, sektorforpligtelser, lovgivning, kontrakter, interne regler og eksisterende kontroller i risikovurderingens baseline. Standarden fremhæver også kriterier for sandsynlighed, konsekvens, retlige forpligtelser, leverandørrelationer, påvirkning af privatliv og påvirkning fra tredjeparter. I praksis er en sårbarhed ikke blot et CVSS-tal. Den er en risikohændelse knyttet til aktiver, forpligtelser, interessenter og forretningsmæssige konsekvenser.

Det regulatoriske pres bag patchbevismateriale

Moderne cybersikkerhedsregulering tolererer i stigende grad ikke uformel patchning.

NIS2 gælder for mange mellemstore og store enheder i sektorer med høj kritikalitet og kritiske sektorer og kan også omfatte visse enheder uanset størrelse. Omfanget omfatter udbydere af digital infrastruktur såsom cloud computing-tjenester, datacentertjenester, indholdsleveringsnetværk, udbydere af offentlige elektroniske kommunikationstjenester, tillidstjenester, DNS- og TLD-tjenester samt udbydere af administrerede tjenester, herunder MSP’er og MSSP’er. Det omfatter også vigtige digitale udbydere såsom onlinemarkedspladser, onlinesøgemaskiner og sociale netværksplatforme.

Article 20 i NIS2 gør cybersikkerhed til et ledelsesansvar. Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, sikker anskaffelse, sikker udvikling, sikker vedligeholdelse, håndtering og offentliggørelse af sårbarheder, vurdering af effektivitet, cyberhygiejne, adgangsstyring, aktivstyring og autentifikation. Article 23 etablerer en trinvis underretningsproces for væsentlige hændelser, herunder tidlig advarsel inden for 24 timer, underretning inden for 72 timer og, hvor relevant, en endelig rapport inden for én måned.

DORA etablerer et direkte anvendeligt regelsæt for digital operationel robusthed for finansielle enheder fra 17. januar 2025. Det omfatter styring af IKT-risiko, rapportering af større IKT-hændelser, test af operationel robusthed, deling af cybertrusselsintelligens, styring af IKT-tredjepartsrisici og tilsyn med kritiske IKT-tredjepartsleverandører. Articles 5 og 6 placerer IKT-risikostyring under ledelsesorganet og kræver et dokumenteret, integreret og regelmæssigt gennemgået rammeværk for styring af IKT-risiko. Article 8 understreger behovet for at identificere IKT-understøttede forretningsfunktioner, informationsaktiver, IKT-aktiver og afhængigheder. Articles 17 to 20 kræver detektion, registrering, klassificering, eskalering, rapportering, kommunikation, afhjælpning og læring for IKT-relaterede hændelser. Articles 28 to 30 kræver, at IKT-tredjepartsrisici styres gennem registre, due diligence, kontraktlige sikkerhedsforanstaltninger, revisionsrettigheder, exitplanlægning og tilsyn.

For finansielle enheder omfattet af DORA erstatter DORA generelt tilsvarende NIS2-forpligtelser vedrørende risikostyring og rapportering. Men NIS2 er fortsat relevant for økosystemkoordinering og enheder uden for DORA’s anvendelsesområde. For SaaS-, MSP- og MSSP-udbydere, der betjener finansielle kunder, er den praktiske realitet direkte: kunder kan kræve jeres sårbarhedsbevismateriale for at opfylde deres DORA-forpligtelser.

GDPR tilføjer endnu et lag. Articles 2 og 3 kan gælde for organisationer etableret i EU og organisationer uden for EU, der tilbyder varer eller tjenester til personer i EU eller overvåger deres adfærd. Article 5 kræver beskyttelse af personoplysninger og ansvarlighed for overholdelse. Article 4 definerer et brud på persondatasikkerheden som en sikkerhedshændelse, der fører til hændeligt eller ulovligt tab, destruktion, ændring, uautoriseret videregivelse af eller adgang til personoplysninger. En forsinket patch på en database, identitetsplatform eller kundeportal kan blive et spørgsmål om ansvarlighed for privatlivsbeskyttelse.

Fra politik til dokumentation

Første skridt er at definere reglerne. En stærk politik for sårbarheds- og patchstyring er ikke kun et revisionsdokument. Den er det operationelle grundlag for kontrollen.

For enterprise-miljøer forbinder Politik for sårbarheds- og patchstyring eksplicit teknisk patchning med tværgående efterlevelse:

Denne politik understøtter overholdelse af ISO/IEC 27001 Annex A Control 8.8 og ISO/IEC 27002-vejledning og adresserer regulatoriske krav i DORA Article 8, NIS2 Article 21, GDPR Article 32 og COBIT 2019 DSS- og APO-domæner.

Fra afsnittet “Formål”.

Den samme politik fastsætter styringsforventningen til det centrale bevisartefakt:

Et centraliseret register for sårbarhedsstyring skal vedligeholdes af Security Operations-teamet og gennemgås månedligt af CISO eller delegeret myndighed.

Fra afsnittet “Styringskrav”, politikklausul 5.1.

Den definerer også scanningskadencen:

Alle systemer skal scannes mindst månedligt; højrisikoaktiver eller eksternt eksponerede aktiver skal scannes ugentligt.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

Og den forhindrer, at hastende patchning bliver ukontrolleret teknisk aktivitet:

Alle afhjælpningsaktiviteter skal koordineres gennem ændringsstyringsprocessen (i henhold til P5 - Politik for ændringsstyring) for at sikre stabilitet og bevarelse af revisionssporet.

Fra afsnittet “Styringskrav”, politikklausul 5.5.

For SMV’er kan de samme bevisprincipper implementeres enklere. Politik for sårbarheds- og patchstyring for SMV’er angiver:

Vedligehold nøjagtige registreringer over implementerede patches, udestående forhold og undtagelser for at sikre revisionsberedskab

Fra afsnittet “Mål”, politikklausul 3.4.

Den definerer derefter patchloggen som revisionsbevis:

En patchlog skal vedligeholdes og gennemgås under revisioner og aktiviteter vedrørende hændelseshåndtering

Fra afsnittet “Styringskrav”, politikklausul 5.4.1.

Og den specificerer minimumsindholdet:

Logfiler skal omfatte enhedsnavn, anvendt opdatering, patchdato og årsag til eventuel forsinkelse

Fra afsnittet “Styringskrav”, politikklausul 5.4.2.

For hastende internetvendt eksponering fastsætter SMV-politikken et målbart krav:

Kritiske patches skal implementeres senest 3 dage efter frigivelse, især for internetvendte systemer

Fra Politik for sårbarheds- og patchstyring for SMV’er, afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

Disse klausuler omsætter teknisk arbejde til bevismateriale. Politikken definerer forventningerne. Registeret registrerer konstateringer. Sagen tildeler arbejdet. Ændringsregistreringen styrer udrulningen. Patchloggen dokumenterer handlingen. Risikoregisteret registrerer undtagelser. Gennemgangsreferaterne dokumenterer tilsynet.

Clarysecs bevis-først-model

Clarysecs bevis-først-model starter med ét princip: enhver sårbarhedskonstatering skal kunne spores fra opdagelse til beslutning.

I Zenith Blueprint: En auditors 30-trins køreplan behandler fasen Controls in Action, Step 19: Technological Controls I, sårbarhedsstyring som en gentagelig kontrol frem for et teoretisk krav:

Håndtering af sårbarheder er et af de mest kritiske områder inden for moderne cyberhygiejne. Selvom firewalls og antivirusværktøjer giver beskyttelse, kan de undergraves, hvis upatchede systemer eller fejlkonfigurerede tjenester efterlades eksponeret.

Det samme trin forklarer, at organisationer bør anvende faste patchplaner, sårbarhedsscannere, triage, tildeling, sporing af afhjælpning, kompenserende kontroller og accept af restrisiko. Vigtigst er, at det rammesætter revisionstankegangen korrekt:

Kontrollen handler ikke om perfektion; den handler om at have en organiseret, gennemsigtig og ansvarlig proces.

For auditorer er denne skelnen vigtig. En moden organisation kan have åbne sårbarheder og stadig dokumentere kontrol, forudsat at den har risikobaseret prioritering, dokumenteret ejerskab, godkendte undtagelser, kompenserende kontroller og verificeret afhjælpning.

Zenith Blueprint advarer også om, at auditorer vil undersøge dette område nøje:

Dette er en højt prioriteret kontrol for auditorer, og de vil typisk gå i dybden. Forvent at blive spurgt, hvor ofte systemer patches, hvilken proces I følger, når en zero-day annonceres, og hvilke systemer der er sværest at patche.

Derfor bør en CISO ikke møde op til en revision med kun et scanner-dashboard. Bevispakken skal vise styring, proces, udførelse, verifikation og forbedring.

Kortlægning af ISO 27002-kontroller til revisionsbevis

Zenith Controls: Vejledning til tværgående efterlevelse fungerer som et kompas for tværgående efterlevelse ved at kortlægge ISO/IEC 27002:2022-kontroller og vise, hvordan de relaterer sig til revisionsforventninger. For sårbarheds- og patchstyring udgør tre ISO/IEC 27002:2022-kontroller den operationelle trekant.

ISO/IEC 27002:2022 control 8.8, Management of Technical Vulnerabilities, er den centrale kontrol. Den er forebyggende, understøtter fortrolighed, integritet og tilgængelighed, er tilpasset cybersikkerhedsbegreberne Identify og Protect og knytter sig til trussels- og sårbarhedsstyring.

ISO/IEC 27002:2022 control 8.32, Change Management, er også forebyggende. Den forbinder patchning med kontrolleret udrulning, test, godkendelse, tilbagerulning og revisionsbarhed.

ISO/IEC 27002:2022 control 5.36, Compliance with Policies, Rules and Standards for Information Security, sikrer, at processen ikke er valgfri eller afhængig af individuelle helteindsatser. Den forbinder sårbarhedsstyring med overholdelse af politikker, assurance og tilsyn.

Denne kortlægning undgår en almindelig revisionsfejl. Sikkerhed siger: “Vi patchede det.” Drift siger: “Vi udrullede det.” Compliance siger: “Vi kan ikke dokumentere rækkefølgen.” En kortlagt beviskæde giver alle tre teams den samme fortælling.

Den beviskæde auditorer efterspørger

En forsvarlig beviskæde for sårbarhedsstyring har syv faser.

Den praktiske forskel mellem “vi kører scanninger” og “vi er revisionsklare” er kontinuitet. Hvis en sårbarhed ikke kan spores fra opdagelse til lukning, er kontrollen svag. Hvis der findes undtagelser, men ingen har godkendt dem, er processen svag. Hvis patches omgår ændringsstyring, er revisionssporet svagt. Hvis kritiske sårbarheder forbliver åbne uden kompenserende kontroller, er styringen svag.

Politik for overvågning af revision og efterlevelse understøtter automatisering som en del af denne model:

Automatiserede værktøjer skal implementeres til at overvåge konfigurationsefterlevelse, sårbarhedsstyring, patchstatus og styring af privilegeret adgang.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.4.1.

For SMV’er definerer Politik for overvågning af revision og efterlevelse for SMV’er verifikation af tekniske kontroller i praktiske termer:

Verifikation af tekniske kontroller (f.eks. backupstatus, konfiguration af adgangsstyring, patchregistreringer)

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.2.

Små organisationer behøver ikke enterprise-værktøjer for at blive revisionsklare. De har brug for konsistent bevismateriale. Et enkelt register, en sagstavle, en patchlog og en månedlig gennemgang kan være tilstrækkeligt, hvis de er fuldstændige, ajourførte og knyttet til risiko.

Eksempel: Én kritisk konstatering, fuldt revisionsklar

Marias ugentlige eksterne scanning identificerer CVE-2026-12345 på en internetvendt payment API-gateway. Scanneren klassificerer den som kritisk. Tjenesten behandler kunders identitets- og transaktionsmetadata, så GDPR- og DORA-implikationer er mulige. Gatewayen ejes af Platform Engineering, men patchen kræver en kort afbrydelse.

Her er den revisionsklare arbejdsgang.

1. Opret posten i sårbarhedsregisteret

Sikkerhedsteamet registrerer konstateringen i det centrale register:

• Konstaterings-ID: VULN-2026-0142
• Kilde: ugentlig ekstern scanning
• Opdagelsesdato og -tidspunkt
• Aktiv: api-gw-prod-01
• Ejer: Platform Engineering
• Eksponering: internetvendt
• Datakontekst: kundeidentitet og transaktionsmetadata
• Alvorlighed: kritisk
• SLA: 72 timer eller strengere baseret på politik
• Sag: SEC-4821
• Ændringsregistrering: CHG-10988
• Status: afhjælpning planlagt

2. Udfør triage med forretningsmæssig og regulatorisk kontekst

Teamet kontrollerer tilgængelighed af exploits, angrebsflade, autentifikationskrav, forretningsmæssig påvirkning og datafølsomhed. Fordi systemet er internetvendt og understøtter kundearbejdsgange, forbliver sårbarheden kritisk. Risikoejeren er Head of Platform, og CISO underrettes på grund af mulige NIS2-, DORA- og GDPR-implikationer.

ISO/IEC 27005:2022, punkt 7.1 til 7.4, understøtter risikoidentifikation, ejerskab, konsekvens, sandsynlighed og prioritering. Punkt 8.2 til 8.6 understøtter valg af behandling, fastlæggelse af kontroller, SoA-kobling, behandlingsplanlægning og godkendelse af restrisiko.

3. Åbn en kontrolleret nødændring

Patchen planlægges til samme aften. Ændringsregistreringen omfatter leverandørreference, berørte tjenester, testplan, tilbagerulningsplan, vedligeholdelsesvindue, beslutning om kundekommunikation, godkendelser og krav om validering efter udrulning.

Dette understøtter direkte ISO/IEC 27002:2022 control 8.32 og enterprise-politikkens krav om at koordinere afhjælpning gennem ændringsstyring.

4. Implementér patchen og opdater patchloggen

Patchloggen registrerer enhedsnavn, anvendt opdatering, patchdato og eventuel årsag til forsinkelse. Hvis patchning var blevet forsinket, ville teamet dokumentere kompenserende kontroller såsom WAF-regler, midlertidige adgangsbegrænsninger, øget logning, isolering eller skærpet overvågning.

5. Verificér og luk

Sikkerhed genscanner API-gatewayen. Sårbarheden vises ikke længere. Sagen opdateres med bevismateriale fra ren scanning, patchversion, udrulningstidsstempel og link til ændringsregistrering. Sårbarhedsregisterets status ændres til “Lukket, verificeret”.

6. Gennemgå rapporteringspåvirkning

Hvis der ikke var udnyttelse og ingen driftsafbrydelse, udløses hændelsesrapportering efter NIS2 eller DORA muligvis ikke. Hvis kompromitteringsindikatorer findes, skal hændelsesprocessen klassificere påvirkning og eskalering. Under NIS2 kan en væsentlig hændelse kræve tidlig advarsel og trinvis rapportering. Under DORA kræver en større IKT-relateret hændelse klassificering og rapportering gennem den relevante kompetente myndigheds proces.

7. Indarbejd læring i ledelsens gennemgang

Ved månedens afslutning noterer CISO-gennemgangen, at sårbarheden blev detekteret ved ugentlig ekstern scanning, afhjulpet inden for SLA, verificeret ved genscanning og lukket uden hændelse. Hvis lignende forhold gentager sig, kan behandlingsplanen omfatte sikre konfigurationsbaselines, automatiseret patchudrulning, leverandøreskalering eller modernisering af applikationen.

Når en auditor spørger til CVE-2026-12345, kan Maria fremlægge en kurateret pakke i stedet for e-mails og skærmbilleder.

Det er revisionsklart. Ikke fordi organisationen ikke havde sårbarheder, men fordi den havde kontrol.

Ét sæt bevismateriale, flere forpligtelser

Et veldesignet program for sårbarheds- og patchstyring kan opfylde flere rammeværker uden at duplikere arbejde.

For ISO 27001:2022 understøtter bevismaterialet det risikobaserede ISMS, implementering af Annex A-kontroller, Statement of Applicability, risikobehandlingsplaner, intern revision og løbende forbedring. Hvis ISO/IEC 27002:2022 control 8.8 er anvendelig i SoA, bør organisationen kunne vise den retlige, regulatoriske, risikomæssige eller forretningsmæssige begrundelse. Denne begrundelse omfatter ofte NIS2 Article 21, DORA IKT-risikoforpligtelser, GDPR-ansvarlighed, kundekontrakter og behov for operationel robusthed.

For NIS2 hjælper det samme bevismateriale med at dokumentere foranstaltninger efter Article 21, herunder risikoanalyse, håndtering af sårbarheder, hændelseshåndtering, forretningskontinuitet, forsyningskædesikkerhed, cyberhygiejne, adgangsstyring og vurdering af effektivitet. Article 20 dokumenteres gennem CISO-gennemgang, bestyrelsesrapportering, ledelsesgodkendelse og cybersikkerhedstræning. Article 23 bliver relevant, hvis udnyttelse forårsager eller kan forårsage alvorlige driftsforstyrrelser, økonomisk tab eller skade på andre.

For DORA understøtter sårbarheds- og patchbevismateriale rammeværket for styring af IKT-risiko, ledelsesorganets tilsyn, robusthedsstrategi, hændelsesdetektion og klassificering, robusthedstest og tilsyn med IKT-tredjeparter. Hvor en IKT-udbyder hoster eller administrerer det berørte system, kræver Articles 28 to 30 due diligence, kontraktlige beskyttelser, revisionsrettigheder, bistand ved hændelser og exitovervejelser.

For GDPR understøtter det samme bevismateriale ansvarlighed efter Article 5 og det sikkerhedsniveau, der forventes efter Article 32. Hvis en sårbarhed fører til uautoriseret adgang, ændring, tab eller videregivelse af personoplysninger, bliver sårbarhedstidslinjen, patchregistreringer, overvågningslogfiler og noter fra brudvurderingen afgørende.

For COBIT 2019 og ISACA-lignende assurance vurderes sårbarhedsstyring gennem driftssikkerhed, kontrolovervågning, change enablement og styringsmæssig ansvarlighed. Zenith Blueprint’s referencer til tværgående efterlevelse fremhæver COBIT 2019 DSS05.04 og BAI09.02 samt ITAF-assuranceforventninger til sårbarhedsstyring, patchning og sikker ændringsstyring.

Understøttende ISO-standarder styrker den operationelle model. ISO/IEC 27005:2022 understøtter risikovurdering og risikobehandling. ISO/IEC 27035:2023 understøtter hændelseshåndtering, når sårbarheder udnyttes. ISO/IEC 30111 understøtter processer for håndtering af sårbarheder. ISO/IEC 29147 understøtter offentliggørelse af sårbarheder og meddelelser. ISO/IEC 27017 understøtter sårbarhedsstyring i cloud. ISO 22301 understøtter kontinuitetsplanlægning, hvor tekniske sårbarheder kan forstyrre forretningstjenester.

Hvordan forskellige auditorer tester den samme proces

Forskellige assessorer bruger forskellige perspektiver. Bevismaterialet kan være det samme, men spørgsmålene ændrer sig.

Politikken siger, hvad der skal ske. Det operationelle bevismateriale viser, hvad der faktisk skete. Gennemgangsregistreringerne viser, at ledelsen kendte forholdene, udfordrede dem og handlede.

Almindelige årsager til, at patchstyring fejler i en revision

De fleste konstateringer skyldes ikke fraværet af en scanner. De skyldes brudt sporbarhed.

Aktivfortegnelsen er ufuldstændig.
Hvis en scanner finder aktiver, der mangler i CMDB’en eller aktivregisteret, kan ejerskab og forretningsmæssig påvirkning ikke vurderes pålideligt. Det underminerer ISO 27001:2022-omfang, risikovurdering og behandling.

Sårbarheder spores kun i scanneren.
Scanner-dashboards er ikke styringsregistre. De mangler ofte risikoejerens godkendelse, begrundelse for undtagelser, ændringsreferencer og forretningskontekst.

Kritiske konstateringer har intet SLA-bevismateriale.
En politik kan sige, at kritiske sårbarheder rettes inden for tre dage. Revisionsspørgsmålet er, om registreringer dokumenterer, at det skete.

Undtagelser er uformelle.
Legacy-systemer, begrænsninger ved nedetid og leverandørforsinkelser forekommer. Men “vi kunne ikke patche det” skal omsættes til en dokumenteret undtagelse med kompenserende kontroller, udløbsdato og godkendelse af restrisiko.

Nødpatchning omgår ændringsstyring.
Nødændringer er stadig ændringer. Hvis der ikke findes godkendelse, test eller bevismateriale for tilbagerulning, kan auditorer konkludere, at afhjælpningen skabte driftsrisiko.

Tredjepartssystemer er usynlige.
Under NIS2 og DORA er leverandør- og IKT-tredjepartsrisiko centrale. Hvis en udbyder patcher platformen, har I stadig brug for bevismateriale, kontraktlige rettigheder, servicerapportering og eskalationsveje.

Ingen gennemgår tendenser.
Tilbagevendende sårbarheder kan indikere svag konfigurationsstyring, mangelfuld praksis for sikker udvikling, ikke-understøttede aktiver eller leverandørsvigt. Månedlig gennemgang omsætter tekniske data til styringshandling.

Clarysecs revisionspakke for sårbarheder

Til en kommende ISO 27001:2022-, NIS2- eller DORA-parathedsgennemgang hjælper Clarysec organisationer med at samle en revisionspakke for sårbarheds- og patchstyring med følgende:

• Politik for sårbarheds- og patchstyring, herunder omfang, roller, scanningskadence, patch-SLA’er og regler for undtagelser
• Udtræk fra aktivfortegnelse, der viser systemer i scope, ejere, kritikalitet og eksponering
• Seneste interne og eksterne sårbarhedsscanningsrapporter
• Centralt register for sårbarhedsstyring med åbne, lukkede og undtagelsesposter
• Patchlogfiler, der viser enhed, opdatering, patchdato og årsager til forsinkelse
• Ændringsregistreringer for udvalgte kritiske og høje sårbarheder
• Bevismateriale for genscanninger eller validering efter afhjælpning
• Godkendelser af undtagelser og restrisiko for forsinkede eller ikke-patchbare systemer
• Proces for overvågning af sikkerhedsmeddelelser fra leverandører, biblioteker og cloudtjenester
• Månedlige CISO- eller ledelsesgennemgangsreferater
• Crosswalk til forpligtelser i ISO 27001:2022, NIS2, DORA, GDPR og COBIT 2019
• Resultater fra intern revision eller verifikation af tekniske kontroller

I Zenith Blueprint, fasen Audit, Review & Improvement, Step 24, fremhæver Clarysec sporbarhed mellem Statement of Applicability, risikoregisteret og behandlingsplanen:

Jeres SoA bør være konsistent med jeres risikoregister og risikobehandlingsplan. Dobbelttjek, at hver kontrol, I har valgt som risikobehandling, er markeret som “anvendelig” i SoA.

Dette er særligt vigtigt for sårbarhedsstyring. Hvis control 8.8 er anvendelig, bør revisionspakken dokumentere ikke blot, at scanning finder sted, men at konstateringer styres gennem risikobehandling og løbende forbedring.

Et 30-dages parathedssprint

Hvis revisionen er tæt på, skal I ikke begynde med at omskrive alt. Start med hurtigt at opbygge bevismateriale.

Dette sprint eliminerer ikke al teknisk gæld. Det ændrer revisionssamtalen. I stedet for at forsvare en rodet scannereksport kan I vise en styret proces med ejere, tidslinjer, handlinger, beslutninger og tilsyn.

Gå fra scanninger til forsvarligt bevismateriale

Revisionsberedskab for sårbarheds- og patchstyring handler ikke om at bevise, at I ikke har sårbarheder. Det handler om at bevise, at I kan finde dem, forstå dem, prioritere dem, rette dem, kontrollere undtagelser og dokumentere tilsyn.

Clarysecs Zenith Blueprint, Zenith Controls, Politik for sårbarheds- og patchstyring, Politik for sårbarheds- og patchstyring for SMV’er, Politik for overvågning af revision og efterlevelse og Politik for overvågning af revision og efterlevelse for SMV’er giver strukturen til at opbygge denne arbejdsgang for bevismateriale.

Hvis jeres organisation forbereder sig på ISO 27001:2022-certificering, NIS2-parathed, DORA digital operationel robusthed, kunders due diligence eller intern revision, så begynd med ét spørgsmål:

Kan enhver kritisk sårbarhed spores fra scanning til lukning?

Hvis svaret er nej, kan Clarysec hjælpe jer med at opbygge registeret, politiksættet, kortlægningen af tværgående efterlevelse, ledelsesgennemgangspakken og den revisionsklare arbejdsgang for bevismateriale, der omsætter teknisk scanning til forsvarlig styring.