Från skanningar till revisionsbevis: ISO 27001:2022, NIS2, DORA

Klockan är 08:16 en måndagsmorgon. En kritisk sårbarhet för fjärrkörning av kod har precis dykt upp i kontrollpanelen för en internetexponerad applikationsserver. Infrastrukturteamet säger att leverantörens patch finns tillgänglig. Applikationsägaren varnar för att servern stödjer ett intäktskritiskt kundarbetsflöde. Juridik frågar om ett utnyttjande kan utlösa rapportering enligt NIS2, DORA eller GDPR. CISO:n, Maria, öppnar revisionskalendern och ser det verkliga problemet: den uppföljande revisionen för ISO 27001:2022 börjar nästa vecka, en beredskapsgranskning för NIS2 pågår redan och en större fintechkund har begärt DORA-underlag.

Skannern visar rött. Ärendetavlan visar aktivitet. Kalkylarket visar arbetsinsats. Men inget av detta visar automatiskt att kontrollen fungerar.

Detta är den lucka många organisationer upptäcker för sent. Sårbarhetsskanning är inte samma sak som revisionsberedskap för sårbarhetshantering. En skanning visar att något kan vara fel. Revisionsbevis visar att organisationen visste vilka tillgångar den hade, bedömde risk, tilldelade ägarskap, agerade enligt policy, styrde ändringar, dokumenterade undantag, verifierade resultat och granskade utfallet.

För ISO/IEC 27001:2022, NIS2 och DORA är denna beviskedja lika viktig som den tekniska åtgärden. Skannern inleder berättelsen. Tillgångsförteckningen, sårbarhetsregistret, ärendet, riskbeslutet, ändringsposten, patchloggen, valideringsunderlaget, godkännandet av undantag och ledningens genomgång fullbordar den.

Clarysecs arbetssätt är enkelt: behandla inte sårbarhetshantering som en teknisk månadsritual. Behandla den som ett styrt arbetsflöde för bevismaterial.

Varför skanningsrapporter inte räcker som revisionsbevis

En sårbarhetsskanning är en teknisk observation vid en viss tidpunkt. Den kan identifiera en CVE, en saknad patch, ett bibliotek utan stöd, en exponerad tjänst eller en svag konfiguration. Det är användbart, men inte komplett.

En revisor ställer andra frågor:

• Ingick den berörda tillgången i omfattningen?
• Vem äger tillgången och verksamhetstjänsten?
• Bedömdes sårbarheten utifrån exponering, exploaterbarhet, affärskonsekvens och datakänslighet?
• Genomfördes åtgärden inom den definierade tidsfristen?
• Om åtgärden försenades, vem accepterade den kvarstående risken?
• Driftsattes patchen genom kontrollerad ändringshantering?
• Verifierades åtgärden genom omskanning eller teknisk validering?
• Bevarades bevismaterialet och granskades det av ledningen?

En mapp med exporter från skanningsverktyg besvarar sällan dessa frågor. Vid en revision enligt ISO 27001:2022 testar revisorn om ISMS fungerar som avsett. Enligt NIS2 ska ledningsorgan godkänna och utöva tillsyn över cybersäkerhetsåtgärder för riskhantering. Enligt DORA behöver finansiella entiteter ett dokumenterat ramverk för IKT-riskhantering, en incidentlivscykel, resiliensprovning och kontroller för IKT-tredjepartsrisk. Enligt GDPR blir frågan om lämpliga tekniska och organisatoriska åtgärder skyddade personuppgifter och om ansvarsskyldighet kan visas.

ISO/IEC 27001:2022 avsnitt 4.1 till 4.4 kräver att organisationen förstår sitt sammanhang, sina intressenter, krav och ISMS-omfattning. Sårbarhets- och patchhantering kan inte utformas isolerat. Den måste spegla kundavtal, tillsynsmyndigheter, molnberoenden, outsourcade IKT-tjänster, dataskyddsskyldigheter och kritiska tjänster.

ISO/IEC 27001:2022 avsnitt 6.1.1 till 6.1.3 kräver riskbedömning, riskbehandling, urval av kontroller, en tillämpbarhetsförklaring och riskägarens godkännande av kvarstående risk. Det innebär att sårbarhetsunderlag bör kopplas till riskregistret, riskbehandlingsplanen och SoA.

ISO/IEC 27005:2022 förstärker denna modell genom att uppmuntra organisationer att konsolidera krav från Annex A, sektorskrav, regelverk, avtal, interna regler och befintliga kontroller i riskbedömningens baslinje. Standarden betonar även kriterier för sannolikhet, konsekvens, rättsliga skyldigheter, leverantörsrelationer, integritetspåverkan och tredjepartspåverkan. I praktiken är en sårbarhet inte bara ett CVSS-värde. Den är en riskhändelse kopplad till tillgångar, skyldigheter, intressenter och verksamhetskonsekvenser.

Det regulatoriska trycket bakom patchunderlag

Modern cybersäkerhetsreglering har allt mindre tolerans för informell patchning.

NIS2 gäller många medelstora och stora entiteter i högkritiska och kritiska sektorer, och kan även omfatta vissa entiteter oavsett storlek. Tillämpningsområdet inkluderar leverantörer av digital infrastruktur såsom molntjänster, datacentertjänster, innehållsleveransnätverk, leverantörer av allmänna elektroniska kommunikationer, betrodda tjänster, DNS- och TLD-tjänster samt leverantörer av IKT-tjänstehantering såsom leverantörer av hanterade tjänster (MSP:er) och leverantörer av hanterade säkerhetstjänster. Det omfattar också viktiga digitala leverantörer såsom online-marknadsplatser, sökmotorer online och plattformar för sociala nätverk.

Article 20 i NIS2 gör cybersäkerhet till ett ansvar för ledningsorganet. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, leveranskedjesäkerhet, säker anskaffning, säker utveckling, säkert underhåll, hantering och rapportering av sårbarheter, effektivitetsbedömning, cyberhygien, åtkomstkontroll, tillgångshantering och autentisering. Article 23 skapar en stegvis process för anmälan av betydande incidenter, inklusive tidig varning inom 24 timmar, anmälan inom 72 timmar och en slutrapport inom en månad när det är tillämpligt.

DORA skapar ett direkt tillämpligt regelverk för digital operativ resiliens för finansiella entiteter från den 17 januari 2025. Det omfattar IKT-riskhantering, rapportering av större IKT-incidenter, testning av operativ resiliens, delning av cyberhotinformation, hantering av IKT-tredjepartsrisk och tillsyn över kritiska IKT-tredjepartsleverantörer. Articles 5 and 6 lägger styrningen av IKT-risk på ledningsorganet och kräver ett dokumenterat, integrerat och regelbundet granskat ramverk för IKT-riskhantering. Article 8 förstärker behovet av att identifiera IKT-stödda verksamhetsfunktioner, informationstillgångar, IKT-tillgångar och beroenden. Articles 17 to 20 kräver detektering, registrering, klassificering, eskalering, rapportering, kommunikation, avhjälpande åtgärder och lärande för IKT-relaterade incidenter. Articles 28 to 30 kräver att IKT-tredjepartsrisk styrs genom register, leverantörsgranskning, avtalsmässiga skyddsåtgärder, revisionsrätt, exitplanering och tillsyn.

För finansiella entiteter som omfattas av DORA ersätter DORA normalt motsvarande krav i NIS2 på riskhantering och rapportering. Men NIS2 är fortfarande relevant för ekosystemsamordning och entiteter utanför DORA:s tillämpningsområde. För SaaS-, MSP- och MSSP-leverantörer som betjänar finansiella kunder är den praktiska verkligheten direkt: kunder kan kräva ert sårbarhetsunderlag för att uppfylla sina DORA-skyldigheter.

GDPR lägger till ytterligare ett lager. Articles 2 and 3 kan gälla organisationer etablerade i EU och organisationer utanför EU som erbjuder varor eller tjänster till personer i EU eller övervakar deras beteende. Article 5 kräver skydd av personuppgifter och ansvarsskyldighet för efterlevnad. Article 4 definierar en personuppgiftsincident som en säkerhetsincident som leder till oavsiktlig eller olaglig förlust, förstöring, ändring, obehörigt röjande av eller åtkomst till personuppgifter. En försenad patch på en databas, identitetsplattform eller kundportal kan bli en fråga om ansvarsskyldighet inom dataskydd.

Från policy till bevismaterial

Första steget är att definiera reglerna. En stark policy för sårbarhets- och patchhantering är inte bara ett revisionsdokument. Den är den operativa grundlagen för kontrollen.

För företagsmiljöer kopplar Policy för sårbarhets- och patchhantering uttryckligen teknisk patchning till tvärgående efterlevnad:

Denna policy stödjer efterlevnad av ISO/IEC 27001 Annex A-kontroll 8.8 och vägledning i ISO/IEC 27002 samt hanterar regulatoriska krav enligt DORA Article 8, NIS2 Article 21, GDPR Article 32 och COBIT 2019 DSS- och APO-domänerna.

Från avsnittet ”Syfte”.

Samma policy anger styrningsförväntan för den centrala bevisartefakten:

Ett centraliserat sårbarhetshanteringsregister ska underhållas av säkerhetsoperationsteamet och granskas månadsvis av CISO eller delegerad befattningshavare.

Från avsnittet ”Styrningskrav”, policyklausul 5.1.

Den definierar också skanningsfrekvens:

Alla system ska skannas minst månadsvis; högrisktillgångar eller externt exponerade tillgångar ska skannas veckovis.

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

Och den förhindrar att akut patchning blir okontrollerad teknisk aktivitet:

Alla avhjälpande åtgärder ska samordnas genom processen för ändringshantering (enligt P5 – policy för ändringshantering) för att säkerställa stabilitet och bevarande av revisionsspår.

Från avsnittet ”Styrningskrav”, policyklausul 5.5.

För små och medelstora företag kan samma evidensprinciper införas enklare. Policy för sårbarhets- och patchhantering för små och medelstora företag anger:

Upprätthåll korrekta poster över installerade patchar, kvarstående problem och undantag för att säkerställa revisionsberedskap

Från avsnittet ”Mål”, policyklausul 3.4.

Den definierar därefter patchloggen som revisionsbevis:

En patchlogg ska underhållas och granskas vid revisioner och incidenthanteringsaktiviteter

Från avsnittet ”Styrningskrav”, policyklausul 5.4.1.

Och den anger minimiinnehållet:

Loggar ska omfatta enhetsnamn, installerad uppdatering, patchningsdatum och skäl till eventuell försening

Från avsnittet ”Styrningskrav”, policyklausul 5.4.2.

För akut internetexponerad exponering fastställer SME-policyn ett mätbart krav:

Kritiska patchar ska installeras inom 3 dagar från publicering, särskilt för internetexponerade system

Från Policy för sårbarhets- och patchhantering för små och medelstora företag, avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

Dessa klausuler omvandlar tekniskt arbete till bevismaterial. Policyn definierar förväntningar. Registret dokumenterar iakttagelser. Ärendet tilldelar arbete. Ändringsposten styr driftsättningen. Patchloggen visar åtgärd. Riskregistret fångar undantag. Protokoll från granskningar visar tillsyn.

Clarysecs evidensbaserade modell

Clarysecs evidensbaserade modell utgår från en princip: varje sårbarhetsiakttagelse ska kunna spåras från upptäckt till beslut.

I Zenith Blueprint: revisorns färdplan i 30 steg behandlar fasen Kontroller i praktiken, steg 19: Tekniska kontroller I, sårbarhetshantering som en återkommande kontroll snarare än ett teoretiskt krav:

Sårbarhetshantering är ett av de mest kritiska områdena inom modern cyberhygien. Även om brandväggar och antivirusverktyg ger skydd kan de undermineras om opatchade system eller felkonfigurerade tjänster lämnas exponerade.

Samma steg förklarar att organisationer bör använda regelbundna patchningsscheman, sårbarhetsskannrar, triage, tilldelning, uppföljning av avhjälpande åtgärder, kompenserande kontroller och acceptans av kvarstående risk. Viktigast av allt är att det ramar in revisionsperspektivet korrekt:

Kontrollen handlar inte om perfektion, utan om att ha en organiserad, transparent och ansvarstagande process.

För revisorer är denna skillnad viktig. En mogen organisation kan ha öppna sårbarheter och ändå visa kontroll, förutsatt att den har riskbaserad prioritering, dokumenterat ägarskap, godkända undantag, kompenserande kontroller och verifierade avhjälpande åtgärder.

Zenith Blueprint varnar också för att revisorer kommer att granska detta område noggrant:

Detta är en högprioriterad kontroll för revisorer, och de går vanligtvis på djupet. Räkna med frågor om hur ofta system patchas, vilken process ni följer när en zero-day tillkännages och vilka system som är svårast att patcha.

Därför ska en CISO inte gå in i en revision med enbart en skannerpanel. Evidenspaketet måste visa styrning, process, genomförande, verifiering och förbättring.

Mappning av ISO 27002-kontroller till revisionsbevis

Zenith Controls: vägledning för tvärgående efterlevnad fungerar som en kompass för tvärgående efterlevnad genom att mappa ISO/IEC 27002:2022-kontroller och visa hur de relaterar till revisionsförväntningar. För sårbarhets- och patchhantering utgör tre ISO/IEC 27002:2022-kontroller den operativa triangeln.

ISO/IEC 27002:2022 kontroll 8.8, hantering av tekniska sårbarheter, är den centrala kontrollen. Den är förebyggande, stödjer konfidentialitet, riktighet och tillgänglighet, är i linje med cybersäkerhetsbegreppen Identify och Protect och kopplas till hot- och sårbarhetshantering.

ISO/IEC 27002:2022 kontroll 8.32, ändringshantering, är också förebyggande. Den kopplar patchning till kontrollerad driftsättning, testning, godkännande, återgång och revisionsbarhet.

ISO/IEC 27002:2022 kontroll 5.36, efterlevnad av policyer, regler och standarder för informationssäkerhet, säkerställer att processen inte är frivillig eller beroende av individuella hjältedåd. Den kopplar sårbarhetshantering till policyefterlevnad, kontrollsäkring och tillsyn.

Denna mappning undviker ett vanligt revisionsmisslyckande. Säkerhet säger: ”Vi patchade det.” Drift säger: ”Vi driftsatte det.” Regelefterlevnad säger: ”Vi kan inte visa sekvensen.” En mappad beviskedja ger alla tre teamen samma berättelse.

Beviskedjan som revisorer vill se

En försvarbar beviskedja för sårbarhetshantering har sju steg.

Den praktiska skillnaden mellan ”vi kör skanningar” och ”vi är revisionsberedda” är kontinuitet. Om en sårbarhet inte kan spåras från upptäckt till stängning är kontrollen svag. Om undantag finns men ingen har godkänt dem är processen svag. Om patchar kringgår ändringshantering är revisionsspåret svagt. Om kritiska sårbarheter förblir öppna utan kompenserande kontroller är styrningen svag.

Policy för revision och efterlevnadsövervakning stödjer automatisering som en del av denna modell:

Automatiserade verktyg ska införas för att övervaka konfigurationsefterlevnad, sårbarhetshantering, patchstatus och privilegierad åtkomst.

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.4.1.

För små och medelstora företag definierar Policy för revision och efterlevnadsövervakning för små och medelstora företag verifiering av tekniska kontroller i praktiska termer:

Verifiering av tekniska kontroller (t.ex. status för säkerhetskopiering, konfiguration av åtkomstkontroll, patchposter)

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.2.

Små organisationer behöver inte verktyg på företagsnivå för att bli revisionsberedda. De behöver konsekvent bevismaterial. Ett lättviktigt register, en ärendetavla, en patchlogg och en månadsgranskning kan räcka om de är fullständiga, aktuella och kopplade till risk.

Exempel: en kritisk iakttagelse med full revisionsberedskap

Marias veckovisa externa skanning identifierar CVE-2026-12345 på en internetexponerad betalnings-API-gateway. Skannern klassar den som kritisk. Tjänsten behandlar kundidentitet och transaktionsmetadata, vilket gör att GDPR- och DORA-konsekvenser är möjliga. Gatewayen ägs av Platform Engineering, men patchen kräver ett kort avbrott.

Så här ser det revisionsklara arbetsflödet ut.

1. Skapa posten i sårbarhetsregistret

Säkerhetsteamet registrerar iakttagelsen i det centrala registret:

• Iakttagelse-ID: VULN-2026-0142
• Källa: veckovis extern skanning
• Upptäcktsdatum och tid
• Tillgång: api-gw-prod-01
• Ägare: Platform Engineering
• Exponering: internetexponerad
• Datakontext: kundidentitet och transaktionsmetadata
• Allvarlighetsgrad: kritisk
• SLA: 72 timmar eller striktare enligt policy
• Ärende: SEC-4821
• Ändringspost: CHG-10988
• Status: avhjälpande åtgärd planerad

2. Triagera utifrån verksamhetsmässig och regulatorisk kontext

Teamet kontrollerar tillgång till exploit, angreppsyta, autentiseringskrav, affärskonsekvens och datakänslighet. Eftersom systemet är internetexponerat och stödjer kundarbetsflöden kvarstår sårbarheten som kritisk. Riskägaren är Head of Platform och CISO informeras på grund av möjliga konsekvenser enligt NIS2, DORA och GDPR.

ISO/IEC 27005:2022 avsnitt 7.1 till 7.4 stödjer riskidentifiering, ägarskap, konsekvens, sannolikhet och prioritering. Avsnitt 8.2 till 8.6 stödjer val av riskbehandling, fastställande av kontroller, SoA-koppling, behandlingsplanering och godkännande av kvarstående risk.

3. Öppna en kontrollerad akut ändring

Patchen schemaläggs till samma kväll. Ändringsposten innehåller leverantörsreferens, berörda tjänster, testplan, rollback-plan, underhållsfönster, beslut om kundkommunikation, godkännanden och krav på validering efter driftsättning.

Detta stödjer direkt ISO/IEC 27002:2022 kontroll 8.32 och företagspolicyns krav på att samordna avhjälpande åtgärder genom ändringshantering.

4. Installera patchen och uppdatera patchloggen

Patchloggen registrerar enhetsnamn, installerad uppdatering, patchningsdatum och skäl till eventuell försening. Om patchningen hade försenats skulle teamet dokumentera kompenserande kontroller såsom WAF-regler, tillfälliga åtkomstbegränsningar, ökad loggning, isolering eller förstärkt övervakning.

5. Verifiera och stäng

Säkerhet gör en omskanning av API-gatewayen. Sårbarheten visas inte längre. Ärendet uppdateras med underlag från ren skanning, patchversion, tidsstämpel för driftsättning och länk till ändringspost. Sårbarhetsregistrets status ändras till ”Stängd, verifierad”.

6. Granska rapporteringspåverkan

Om inget utnyttjande och inget tjänsteavbrott förekom behöver incidentrapportering enligt NIS2 eller DORA kanske inte utlösas. Om indikatorer på kompromettering hittas måste incidentprocessen klassificera påverkan och eskalering. Enligt NIS2 kan en betydande incident kräva tidig varning och stegvis rapportering. Enligt DORA kräver en större IKT-relaterad incident klassificering och rapportering genom den tillämpliga behöriga myndighetsprocessen.

7. För in lärdomar i ledningens genomgång

Vid månadens slut noterar CISO-granskningen att sårbarheten detekterades genom veckovis extern skanning, åtgärdades inom SLA, verifierades genom omskanning och stängdes utan incident. Om liknande problem återkommer kan riskbehandlingsplanen omfatta säkra konfigurationsbaslinjer, automatiserad patchdriftsättning, leverantörseskalering eller modernisering av applikationen.

När en revisor frågar om CVE-2026-12345 kan Maria presentera ett sammanställt paket i stället för e-post och skärmbilder.

Det är revisionsberedskap. Inte för att organisationen saknade sårbarheter, utan för att den hade kontroll.

Ett evidenspaket, flera skyldigheter

Ett väl utformat program för sårbarhets- och patchhantering kan uppfylla flera ramverk utan dubbelarbete.

För ISO 27001:2022 stödjer bevismaterialet ett riskbaserat ISMS, införande av Annex A-kontroller, tillämpbarhetsförklaring, riskbehandlingsplaner, internrevision och ständig förbättring. Om ISO/IEC 27002:2022 kontroll 8.8 är tillämplig i SoA bör organisationen kunna visa den rättsliga, regulatoriska, riskmässiga eller verksamhetsmässiga motiveringen. Den motiveringen omfattar ofta NIS2 Article 21, DORA:s IKT-riskskyldigheter, GDPR:s ansvarsskyldighet, kundavtal och behov av operativ resiliens.

För NIS2 hjälper samma bevismaterial till att visa åtgärder enligt Article 21, inklusive riskanalys, sårbarhetshantering, incidenthantering, verksamhetskontinuitet, leveranskedjesäkerhet, cyberhygien, åtkomstkontroll och effektivitetsbedömning. Article 20 visas genom CISO-granskning, styrelserapportering, ledningsgodkännande och cybersäkerhetsutbildning. Article 23 blir relevant om utnyttjande orsakar eller kan orsaka allvarlig driftstörning, ekonomisk förlust eller skada för andra.

För DORA stödjer sårbarhets- och patchunderlag ramverket för IKT-riskhantering, ledningsorganets tillsyn, resiliensstrategi, incidentdetektering och klassificering, resiliensprovning och tillsyn över IKT-tredjeparter. När en IKT-leverantör hostar eller hanterar det berörda systemet kräver Articles 28 to 30 leverantörsgranskning, avtalsmässiga skydd, revisionsrätt, incidentstöd och exitöverväganden.

För GDPR stödjer samma bevismaterial Article 5 ansvarsskyldighet och det säkerhetsläge som förväntas enligt Article 32. Om en sårbarhet leder till obehörig åtkomst, ändring, förlust eller röjande av personuppgifter blir sårbarhetens tidslinje, patchposter, övervakningsloggar och anteckningar från incidentbedömning centrala.

För COBIT 2019 och ISACA-liknande kontrollsäkring bedöms sårbarhetshantering genom driftsäkerhet, kontrollövervakning, möjliggörande av ändringar och ansvarsskyldighet i styrningen. Tvärgående efterlevnadsreferenser i Zenith Blueprint lyfter COBIT 2019 DSS05.04 och BAI09.02 samt ITAF:s förväntningar på kontrollsäkring av sårbarhetshantering, patchning och säker ändringshantering.

Stödjande ISO-standarder stärker den operativa modellen. ISO/IEC 27005:2022 stödjer riskbedömning och riskbehandling. ISO/IEC 27035:2023 stödjer incidenthantering när sårbarheter utnyttjas. ISO/IEC 30111 stödjer processer för hantering av sårbarheter. ISO/IEC 29147 stödjer sårbarhetsrapportering och säkerhetsmeddelanden. ISO/IEC 27017 stödjer sårbarhetshantering i molnmiljö. ISO 22301 stödjer kontinuitetsplanering när tekniska sårbarheter kan störa verksamhetstjänster.

Hur olika revisorer testar samma process

Olika granskare använder olika perspektiv. Bevismaterialet kan vara detsamma, men frågorna förändras.

Policyn anger vad som ska hända. Det operativa bevismaterialet visar vad som hände. Granskningsposterna visar att ledningen kände till, ifrågasatte och agerade.

Vanliga skäl till att patchhantering underkänns vid revision

De flesta iakttagelser orsakas inte av att en skanner saknas. De orsakas av bruten spårbarhet.

Tillgångsförteckningen är ofullständig.
Om en skanner hittar tillgångar som saknas i CMDB eller tillgångsregister kan ägarskap och affärskonsekvens inte bedömas tillförlitligt. Detta undergräver ISO 27001:2022-omfattning, riskbedömning och riskbehandling.

Sårbarheter följs endast i skannern.
Skannerpaneler är inte styrningsregister. De saknar ofta riskägarens godkännande, motivering till undantag, ändringsreferenser och verksamhetskontext.

Kritiska iakttagelser saknar SLA-underlag.
En policy kan säga att kritiska sårbarheter åtgärdas inom tre dagar. Revisionsfrågan är om posterna visar att det faktiskt hände.

Undantag är informella.
Äldre system, avbrottsbegränsningar och leverantörsförseningar förekommer. Men ”vi kunde inte patcha det” måste bli ett dokumenterat undantag med kompenserande kontroller, utgångsdatum och godkännande av kvarstående risk.

Akut patchning kringgår ändringshantering.
Akuta ändringar är fortfarande ändringar. Om det saknas godkännande, testning eller rollback-underlag kan revisorer dra slutsatsen att avhjälpande åtgärder skapade operativ risk.

Tredjepartssystem är osynliga.
Enligt NIS2 och DORA är leverantörsrisk och IKT-tredjepartsrisk centrala. Om en leverantör patchar plattformen behöver ni fortfarande bevismaterial, avtalsrättigheter, tjänsterapportering och eskaleringsvägar.

Ingen granskar trender.
Återkommande sårbarheter kan indikera svag konfigurationshantering, bristande säker kodningspraxis, tillgångar utan stöd eller leverantörsfel. Månadsgranskning omvandlar tekniska data till styrningsåtgärder.

Clarysecs revisionspaket för sårbarheter

Inför en kommande granskning av beredskap för ISO 27001:2022, NIS2 eller DORA hjälper Clarysec organisationer att sätta samman ett revisionspaket för sårbarhets- och patchhantering med följande:

• Policy för sårbarhets- och patchhantering, inklusive omfattning, roller, skanningsfrekvens, patch-SLA:er och undantagsregler
• Utdrag ur tillgångsförteckning som visar system i omfattningen, ägare, kritikalitet och exponering
• Senaste interna och externa sårbarhetsskanningsrapporter
• Centralt sårbarhetshanteringsregister med öppna, stängda och undantagna poster
• Patchloggar som visar enhet, uppdatering, patchdatum och skäl till förseningar
• Ändringsposter för urval av kritiska och höga sårbarheter
• Bevismaterial från omskanningar eller validering efter avhjälpande åtgärder
• Godkännanden av undantag och kvarstående risk för försenade eller opatchbara system
• Process för övervakning av säkerhetsmeddelanden från leverantörer, bibliotek och molntjänster
• Månatliga protokoll från CISO eller ledningens genomgång
• Korsmappning mot skyldigheter enligt ISO 27001:2022, NIS2, DORA, GDPR och COBIT 2019
• Resultat från internrevision eller verifiering av tekniska kontroller

I Zenith Blueprint, fasen Revision, granskning och förbättring, steg 24, betonar Clarysec spårbarhet mellan tillämpbarhetsförklaringen, riskregistret och riskbehandlingsplanen:

Er SoA ska vara konsekvent med ert riskregister och er riskbehandlingsplan. Dubbelkontrollera att varje kontroll som ni valt som riskbehandling är markerad som ”Tillämplig” i SoA.

Detta är särskilt viktigt för sårbarhetshantering. Om kontroll 8.8 är tillämplig ska revisionspaketet inte bara visa att skanning sker, utan att iakttagelser styrs genom riskbehandling och ständig förbättring.

En 30-dagars sprint för beredskap

Om revisionen är nära, börja inte med att skriva om allt. Börja med att snabbt bygga bevismaterial.

Denna sprint kommer inte att eliminera all teknisk skuld. Den kommer att förändra revisionsdialogen. I stället för att försvara en rörig skanningsexport kan ni visa en styrd process med ägare, tidslinjer, åtgärder, beslut och tillsyn.

Gå från skanningar till försvarbart bevismaterial

Revisionsberedskap för sårbarhets- och patchhantering handlar inte om att visa att ni saknar sårbarheter. Det handlar om att visa att ni kan hitta dem, förstå dem, prioritera dem, åtgärda dem, styra undantag och visa tillsyn.

Clarysecs Zenith Blueprint, Zenith Controls, Policy för sårbarhets- och patchhantering, Policy för sårbarhets- och patchhantering för små och medelstora företag, Policy för revision och efterlevnadsövervakning och Policy för revision och efterlevnadsövervakning för små och medelstora företag ger strukturen för att bygga detta arbetsflöde för bevismaterial.

Om organisationen förbereder sig för ISO 27001:2022-certifiering, NIS2-beredskap, DORA digital operativ resiliens, kundens leverantörsgranskning eller internrevision, börja med en fråga:

Kan varje kritisk sårbarhet spåras från skanning till stängning?

Om svaret är nej kan Clarysec hjälpa er att bygga registret, policyuppsättningen, mappningen för tvärgående efterlevnad, paketet för ledningens genomgång och det revisionsklara arbetsflöde som omvandlar teknisk skanning till försvarbar styrning.