CVD för NIS2 och DORA: evidenskarta för ISO 27001

Klockan 08:17 en tisdag tar säkerhetsbrevlådan emot ett meddelande från en oberoende säkerhetsforskare. Ämnesraden är lugn, nästan artig: ”Potentiellt kontoövertagande i er kundportal.” Innehållet är mindre bekvämt. Säkerhetsforskaren hävdar att en kedjad sårbarhet i er SaaS-applikation gör det möjligt för en kundinstans att komma åt en annan kundinstans fakturaposter. Ett proof of concept är bifogat, krypterat med er publicerade PGP-nyckel.

För Maria, ny informationssäkerhetschef på FinanTechSaaS, kunde tidpunkten knappast vara sämre. Hennes företag har just tecknat ett stort avtal med en ledande bank inom EU. Kundens leverantörsgranskningsteam har redan begärt en ”Policy för samordnad sårbarhetsrapportering” och underlag som visar att den är införd, med uttrycklig hänvisning till NIS2 och DORA. Företaget har en security@-e-postadress, men den övervakas av en utvecklare. Det finns inget formellt mottagningsregister, ingen definierad SLA för validering, ingen eskaleringsväg till ledningen och inget revisionsspår.

Tre klockor börjar ticka samtidigt.

Den första är operativ. Är sårbarheten verklig? Går den att utnyttja i produktionsmiljö? Missbrukas den aktivt av någon?

Den andra är regulatorisk. Om kunddata har exponerats inleds bedömningen av personuppgiftsincident enligt GDPR. Om tjänsteleveransen påverkas för en väsentlig eller viktig entitet enligt NIS2 kan trösklar för incidentrapportering utlösas. Om företaget är en finansiell entitet eller en IKT-leverantör som stödjer finansiella tjänster kan DORA:s regler för incidenthantering, klassificering, eskalering och kundkommunikation bli relevanta.

Den tredje gäller underlaget. Sex månader senare kan en ISO/IEC 27001:2022-revisor, tillsynsfunktion inom finanssektorn, kundens assurance-team eller internrevision fråga: ”Visa hur den här sårbarheten hanterades.”

Det är vid den frågan många organisationer upptäcker att samordnad sårbarhetsrapportering inte bara är en säkerhetsbrevlåda. Det är ett styrningssystem. Det kräver policyägarskap, en publik rapporteringskanal, ett triageringsflöde, SLA:er för åtgärdande, leverantörseskalering, beslutslogik för incidenter, dataskyddsgranskning, rapportering till ledningen och försvarbart revisionsunderlag.

Clarysec behandlar CVD som ett integrerat kontrollmönster, inte som en fristående inkorg. I Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint återfinns sårbarhetshantering i fasen kontroller i drift, steg 19: tekniska kontroller I, där vägledningen är tydlig: organisationer ska inte passivt arkivera sårbarhetsiakttagelser, utan triagera dem, tilldela ansvar och följa upp dem till stängning. Samma standard gäller externa rapporter. Om någon berättar hur er tjänst kan fallera blir den verkliga frågan: kan ni visa att ni tog emot, bedömde, prioriterade, åtgärdade, kommunicerade och drog lärdom av rapporten?

Varför CVD nu är en styrelsefråga enligt NIS2 och DORA

Under många år bjöd säkerhetsmedvetna organisationer in etiska hackare att rapportera sårbarheter eftersom det var god praxis. Enligt NIS2 och DORA har denna praxis blivit en del av reglerad digital resiliens.

NIS2 gäller många medelstora och större entiteter i högkritiska och andra kritiska sektorer, inklusive leverantörer av digital infrastruktur, leverantörer av molntjänster, leverantörer av datacentertjänster, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster och vissa digitala leverantörer såsom onlinemarknadsplatser, sökmotorer och sociala nätverksplattformar. Det kan också gälla oavsett storlek för kategorier såsom betrodda tjänsteleverantörer, DNS-tjänsteleverantörer, TLD-register och leverantörer av allmänna elektroniska kommunikationsnät eller allmänt tillgängliga elektroniska kommunikationstjänster.

NIS2 Article 21 kräver att väsentliga och viktiga entiteter inför lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för hantering av cybersäkerhetsrisker med ett allriskperspektiv. Ett av minimiområdena är säkerhet vid anskaffning, utveckling och underhåll av nätverks- och informationssystem, inklusive sårbarhetshantering och rapportering. Samma baslinje omfattar även incidenthantering, säkerhet i leveranskedjan, verksamhetskontinuitet, åtkomstkontroll, policy för tillgångshantering, utbildning, kryptografi och förfaranden för att bedöma kontrolleffektivitet.

NIS2 Article 20 gör också ledningens ansvarsskyldighet uttrycklig. Ledningsorgan ska godkänna åtgärder för hantering av cybersäkerhetsrisker, övervaka genomförandet och genomgå utbildning. För ett CVD-program innebär det att styrelsen eller högsta ledningen ska förstå rapporteringskanalen, sårbarhetshanteringsteamet, tidsfrister för validering, förväntningar på åtgärdande, leverantörsberoenden och utlösande faktorer för incidentrapportering.

DORA skapar en sektorsspecifik ordning för finansiella entiteter från den 17 januari 2025. Den omfattar IKT-riskhantering, rapportering av IKT-relaterade incidenter, testning av digital operativ resiliens, informationsdelning, IKT-tredjepartsrisk, avtalskrav, tillsyn över kritiska IKT-tredjepartsleverantörer och samarbete med tillsynsmyndigheter. För finansiella entiteter som omfattas av DORA har DORA i regel företräde framför NIS2 när det gäller IKT-riskhantering och incidentrapportering, eftersom den är den sektorsspecifika unionsrättsakten. Det praktiska kravet är dock detsamma: finansiella entiteter och IKT-leverantörer som betjänar dem ska driva en strukturerad, dokumenterad och testbar process för att identifiera, analysera, klassificera, eskalera, åtgärda och lära av IKT-svagheter.

En sårbarhetsrapport kan börja som en teknisk iakttagelse, bli en säkerhetshändelse, eskalera till en incident, utlösa en bedömning av personuppgiftsincident enligt GDPR, kräva åtgärder från leverantör och senare synas i ISO/IEC 27001:2022-tillämplighetsförklaringen. Därför bör CVD utformas som en gemensam operativ modell för säkerhet, regelefterlevnad, utveckling, juridik, dataskydd, upphandling och ledning.

ISO 27001-grunden: från rapportering till ISMS-underlag

ISO/IEC 27001:2022 ger informationssäkerhetschefer och ansvariga för regelefterlevnad det ledningssystem som gör CVD möjlig att granska.

Klausulerna 4.1 till 4.4 kräver att organisationen förstår interna och externa frågor, intressentkrav, ISMS-gränser och beroenden till andra organisationer. Det är här NIS2, DORA, GDPR, kundavtal, leverantörsförpliktelser och åtaganden för sårbarhetsrapportering förs in i ISMS.

Klausulerna 5.1 till 5.3 skapar ansvarsskyldighet för ledarskapet. Högsta ledningen ska anpassa informationssäkerheten till den strategiska inriktningen, tillhandahålla resurser, tilldela ansvar och säkerställa att ISMS uppnår avsedda resultat. För CVD innebär det att utse en sårbarhetsresponsgrupp (VRT), definiera befogenhet att acceptera kvarstående risk och eskalera sårbarheter med hög påverkan till ledningen.

Klausulerna 6.1.1 till 6.1.3 tillhandahåller riskmotorn. Organisationen ska definiera riskkriterier, bedöma informationssäkerhetsrisker, utse riskägare, välja alternativ för riskbehandling, jämföra kontroller mot bilaga A, ta fram en tillämplighetsförklaring och inhämta godkännande för kvarstående risk. Klausulerna 8.1 till 8.3 kräver därefter operativ styrning, planerade ändringar, styrning av externt tillhandahållna processer, riskbedömningar vid planerade intervall eller efter betydande ändringar samt underlag för resultat från riskbehandling.

I Zenith Blueprint, riskhanteringsfasen, steg 13, beskrivs tillämplighetsförklaringen som mer än ett kalkylblad för regelefterlevnad:

”SoA är i praktiken ett bryggdokument: det kopplar er riskbedömning/riskbehandling till de faktiska kontroller ni har.”
Källa: Zenith Blueprint: An Auditor’s 30-Step Roadmap, riskhanteringsfasen, steg 13: planering av riskbehandling och tillämplighetsförklaring (SoA) Zenith Blueprint

För samordnad sårbarhetsrapportering bör SoA bygga bron mellan regulatoriska skyldigheter, verksamhetsrisk, kontroller i bilaga A, policyklausuler och operativt underlag.

Målet är inte att skapa parallella efterlevnadssilor. CVD-policyn bör vara en styrd ISMS-process som samtidigt stödjer ISO/IEC 27001:2022-certifiering, NIS2-efterlevnad, DORA-beredskap, kundförsäkran och säkerhetsdrift.

Policybaslinjen: vad er CVD-policy ska ange

Den första synliga kontrollen är den publika rapporteringskanalen. Säkerhetsforskare, kunder, leverantörer och partner måste veta var de ska rapportera sårbarheter och hur de ska skydda känsligt underlag.

Clarysecs Policy för samordnad sårbarhetsrapportering Policy för samordnad sårbarhetsrapportering ger baslinjen för verksamheten:

”Publika rapporteringskanaler: Organisationen ska upprätthålla en tydlig kanal för sårbarhetsrapportering, såsom en särskild e-postadress för säkerhetskontakt (till exempel security@company.com) eller ett webbformulär. Denna information ska publiceras på företagets säkerhetssida på webbplatsen tillsammans med organisationens publika PGP-nyckel för att möjliggöra krypterade inskick.”
Källa: Policy för samordnad sårbarhetsrapportering, införandekrav, klausul 6.1

Denna klausul löser ett vanligt revisionsfel. Många organisationer hävdar att de tar emot rapporter, men rapporteringsvägen är dold, okrypterad eller ägs av fel team. En mogen kanal är publik, säker, övervakad och tilldelad en ansvarig funktion.

Nästa kontroll är disciplin i responsen. En kritisk rapport som följs av tystnad skapar rapporteringsrisk, anseenderisk och exploateringsrisk. Policy för samordnad sårbarhetsrapportering fastställer en konkret förväntan på bekräftelse och validering:

”Triage och bekräftelse: Vid mottagande av en rapport ska VRT registrera den och skicka en bekräftelse till rapportören inom 2 arbetsdagar samt tilldela en spårningsreferens. VRT ska utföra en preliminär bedömning av allvarlighetsgrad, till exempel med CVSS-poängsättning, och validera problemet, inklusive med stöd från IT- och utvecklingsteam där så krävs, inom en målfrist på 5 arbetsdagar. Kritiska sårbarheter, såsom sådana som möjliggör fjärrkörning av kod eller en större personuppgiftsincident, ska hanteras skyndsamt.”
Källa: Policy för samordnad sårbarhetsrapportering, införandekrav, klausul 6.4

Denna formulering skapar omedelbara underlagspunkter: mottagningstid, bekräftelsetid, spårningsreferens, preliminär allvarlighetsgrad, valideringsutfall och beslut om skyndsam hantering.

För små och medelstora företag använder Clarysec samma logik med proportionerligt införande. Application Security Requirements Policy-sme Application Security Requirements Policy - SME kräver att organisationer:

”specificerar skyldigheter för sårbarhetsrapportering, svarstider och patchning.”
Källa: Application Security Requirements Policy-sme, styrningskrav, klausul 5.3.2

Ni behöver inte ett stort produktsäkerhetsteam för att vara ansvariga. Ni behöver uttryckliga skyldigheter, realistiska tidsramar, namngivna ägare och underlag som visar att processen fungerar.

CVD-mottagningsflödet: från e-post från säkerhetsforskare till beslutsunderlag

Ett bra mottagningsflöde är tillräckligt enkelt för att fungera under press och tillräckligt komplett för att tillfredsställa en revisor. Det bör börja med en särskild kanal, såsom security@[company], ett webbformulär eller en publicerad security.txt-fil. Inskicksvägen bör möjliggöra krypterat underlag, berörd produkt eller slutpunkt, reproduktionssteg, rapportörens kontaktuppgifter, önskad tidpunkt för offentliggörande samt eventuell indikation på dataexponering eller aktiv exploatering.

När rapporten har tagits emot ska sårbarhetsresponsgruppen skapa en post i ett GRC-verktyg, en ärendeplattform, ett system för hantering av sårbarheter eller ett kontrollerat register. Verktyget är mindre viktigt än konsekvens och kvalitet i underlaget.

Arbetsflödet bör därefter gå igenom sju operativa steg.

1. Mottagning: rapporten tas emot via den publika kanalen och loggas automatiskt eller manuellt.
2. Bekräftelse: VRT svarar inom 2 arbetsdagar och tilldelar en spårningsreferens.
3. Validering: det tekniska teamet reproducerar problemet, bekräftar berörda system och utför preliminär poängsättning av allvarlighetsgrad.
4. Händelsebedömning: VRT avgör om sårbarheten endast är en svaghet, en informationssäkerhetshändelse eller en incident.
5. Eskalering: höga eller kritiska ärenden skickas till systemägare, informationssäkerhetschef, dataskydd, juridik, leverantörer och ledning efter behov.
6. Åtgärdande: ansvarigt team tillämpar en korrigering, riskreducerande åtgärd, kompenserande kontroll eller tillfällig begränsning.
7. Stängning: VRT verifierar korrigeringen, kommunicerar med rapportören, uppdaterar underlagsfilen och registrerar erfarenhetsåterföring.

Clarysec mappar detta operativa steg till ISO/IEC 27002:2022 control A.5.25, bedömning av och beslut om informationssäkerhetshändelser, och control A.8.8, hantering av tekniska sårbarheter, genom Zenith Controls: The Cross-Compliance Guide Zenith Controls. För A.5.25 förklarar Zenith Controls att händelsebedömning är triagefunktionen mellan råa övervakningslarm och formell incidenthantering, med hjälp av loggar, trösklar och beslutskriterier för att avgöra eskalering. För A.8.8 kopplar Zenith Controls teknisk sårbarhetshantering till skydd mot skadlig kod, konfigurationshantering, ändringshantering, slutpunktssäkerhet, hotinformation, övervakning, säker utveckling, händelsebedömning och incidentrespons.

Ett avsnitt i Zenith Controls är särskilt användbart när aktiv exploatering misstänks:

”Hotinformation visar vilka sårbarheter som aktivt utnyttjas och vägleder prioriteringen av patchning.”
Källa: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 control 8.8, koppling till control 5.7 Threat Intelligence Zenith Controls

Detta är en viktig styrningspunkt. Allvarlighetsgrad är inte bara CVSS. En sårbarhet med medelhög poäng som aktivt utnyttjas mot er sektor kan ha högre prioritet än ett teoretiskt kritiskt problem i ett icke exponerat testsystem.

När en sårbarhet blir en incident

Alla sårbarhetsrapporter är inte incidenter. En saknad säkerhetsheader i en stagingmiljö är inte samma sak som ett utnyttjat kringgående av behörighetskontroll som exponerar kundfakturor. Men varje trovärdig sårbarhetsrapport ska passera en beslutsgrind för incidenter.

NIS2 Article 23 kräver att väsentliga och viktiga entiteter utan onödigt dröjsmål underrättar sin CSIRT eller behöriga myndighet om incidenter som har betydande påverkan på tillhandahållandet av tjänster. En betydande incident är en incident som har orsakat eller kan orsaka allvarliga driftstörningar eller ekonomisk förlust, eller som har påverkat eller kan påverka andra genom att orsaka betydande materiell eller immateriell skada. Rapporteringssekvensen omfattar en tidig varning inom 24 timmar från det att organisationen fått kännedom, en incidentanmälan inom 72 timmar, mellanrapporter när så begärs och en slutrapport inom en månad från 72-timmarsanmälan.

DORA Articles 17 to 20 kräver att finansiella entiteter detekterar, hanterar, registrerar, klassificerar, eskalerar, anmäler och kommunicerar IKT-relaterade incidenter och betydande cyberhot. Större IKT-relaterade incidenter ska eskaleras till högsta ledningen och ledningsorganet. Kundkommunikation kan krävas när finansiella intressen påverkas.

För små och medelstora företag måste rapporteringskulturen vara lika tydlig. Clarysecs Incident Response Policy-sme Incident Response Policy - SME anger:

”Personal måste rapportera all misstänkt aktivitet eller bekräftad incident till incident@[company] eller muntligen till verkställande direktör eller IT-leverantör.”
Källa: Incident Response Policy-sme, införandekrav för policyn, klausul 6.2.1

I Zenith Blueprint, fasen kontroller i drift, steg 16: personrelaterade kontroller II, är principen ännu enklare:

”Rapportera vid tvekan.”
Källa: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fasen kontroller i drift, steg 16: personrelaterade kontroller II (A.6.5 till A.6.8)

Den formuleringen ska gälla utvecklare, supportteam, leverantörsansvariga, dataskyddsansvariga, ledande befattningshavare och outsourcade leverantörer. En sårbarhet som kan påverka konfidentialitet, riktighet, tillgänglighet, kundförtroende, regulatorisk rapportering eller finansiella operationer ska registreras och bedömas, inte hanteras informellt i en chatt.

Åtgärdande, patchning och kompenserande kontroller

När en sårbarhet har validerats ska den behandlas. Riskbehandlingen ska vara riskbaserad, underbyggd med underlag och tidsbegränsad.

Policy för samordnad sårbarhetsrapportering fastställer organisationens förväntan:

”Åtgärdsplan: En plan för åtgärdande eller riskreducering ska tas fram för alla bekräftade sårbarheter. Genomförandet av korrigeringen ska prioriteras utifrån allvarlighetsgrad. Exempelvis ska kritiska sårbarheter åtgärdas eller riskreduceras inom 14 dagar där det är genomförbart, eller tidigare där aktiv exploatering upptäcks, medan ärenden med lägre allvarlighetsgrad ska hanteras inom rimlig tid. Om en fullständig korrigering fördröjs ska kompenserande kontroller eller tillfälliga riskreducerande åtgärder, såsom att inaktivera sårbar funktionalitet eller öka övervakningen, införas.”
Källa: Policy för samordnad sårbarhetsrapportering, införandekrav, klausul 6.6

För patchdisciplin i små och medelstora företag anger Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME:

”Kritiska patchar måste tillämpas inom 3 dagar från release, särskilt för internetexponerade system”
Källa: Vulnerability and Patch Management Policy-sme, införandekrav för policyn, klausul 6.1.1

Dessa tidsfrister står inte i konflikt med varandra. En leverantörspatch för ett internetexponerat system kan kräva mycket snabb driftsättning. En produktsårbarhet som kräver kodändringar, regressionstestning, kundsamordning och stegvis release kan kräva en åtgärdsplan med interimistiska riskreducerande åtgärder. Det avgörande är att beslutet dokumenteras, ägs av en riskägare och godkänns där kvarstående risk finns.

Ett praktiskt ärendeflöde kan se ut så här:

1. En säkerhetsforskare rapporterar ett kringgående av auktorisering i kundfakturerings-API:et.
2. VRT loggar CVD-2026-014 med tidsstämpel och bekräftar inom 2 arbetsdagar.
3. Produktsäkerhet validerar bristen inom 24 timmar och tilldelar allvarlighetsgraden High på grund av åtkomst till data över kundinstansgränser.
4. Dataskydd genomför en bedömning av personuppgiftsincident enligt GDPR eftersom fakturaposter kan innehålla personuppgifter.
5. Incidentansvarig öppnar en händelsebedömning enligt ISO/IEC 27002:2022 control A.5.25.
6. Systemägaren inaktiverar den sårbara slutpunkten via en tillfällig feature flag.
7. Utveckling skapar en hotfix enligt ISO/IEC 27002:2022 control A.8.32, ändringshantering.
8. Övervakningsregler läggs till för indikatorer på exploatering, kopplade till A.8.15, loggning, och A.8.16, övervakningsaktiviteter.
9. Informationssäkerhetschefen informerar högsta ledningen eftersom problemet är högrisk.
10. VRT samordnar med säkerhetsforskaren kring omtestning och tidpunkt för offentliggörande.
11. Riskägaren godkänner stängning först efter verifieringstestning och granskning av kundpåverkan.
12. SoA, riskregister, ärende, loggar, ledningsavisering och erfarenhetsåterföring uppdateras.

Det är skillnaden mellan ”vi patchade det” och ”vi kan visa att vi styrde det”.

Leverantörs- och molnberoenden: den dolda felpunkten

Många CVD-misslyckanden är leverantörsmisslyckanden i förklädnad. Sårbarheten kan påverka en SaaS-komponent, molntjänst, leverantör av hanterade säkerhetstjänster, betalningsgateway, identitetsförmedlare, bibliotek med öppen källkod, outsourcat utvecklingsteam eller underleverantör.

NIS2 Article 21 kräver säkerhet i leveranskedjan, inklusive relationer med direkta leverantörer och tjänsteleverantörer. Åtgärder för leveranskedjan bör beakta leverantörssårbarheter, produktkvalitet, cybersäkerhetspraxis och säkra utvecklingsrutiner.

DORA Articles 28 to 30 går djupare för finansiella entiteter. De kräver att IKT-tredjepartsrisk hanteras som en del av IKT-riskramverket, med register över IKT-tjänsteavtal, åtskillnad mellan kritiska och viktiga funktioner, leverantörsgranskning före avtal, avtalsbaserade säkerhetskrav, stöd vid incidenter, samarbete med myndigheter, revisionsrätt, rätt att säga upp avtalet och exitstrategier. Finansiella entiteter förblir fullt ansvariga för DORA-efterlevnad även när de använder IKT-tredjepartsleverantörer.

Clarysecs policy för leverantörs- och tredjepartssäkerhet för SME Third-Party and Supplier Security Policy - SME innehåller en enkel eskaleringsregel:

”Måste omedelbart underrätta verkställande direktör om säkerhetsöverträdelse, ändring eller incident”
Källa: Third-Party and Supplier Security Policy-sme, roller och ansvar, klausul 4.4.3

För leverantörsavtal i större organisationer rekommenderar Zenith Blueprint, fasen kontroller i drift, steg 23, att avtalen inkluderar sekretesskyldigheter, ansvar för åtkomstkontroll, tekniska och organisatoriska åtgärder, tidsfrister för incidentrapportering, revisionsrätt, kontroller för underleverantörer och bestämmelser vid avtalets upphörande. Den anger:

”Det viktiga är att de finns och att de förstås och accepteras av båda parter.”
Källa: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fasen kontroller i drift, steg 23: organisatoriska kontroller (5.19 till 5.37)

Leverantörers CVD-beredskap bör besvara följande frågor:

• Publicerar leverantören en kanal för sårbarhetsrapportering?
• Är tidsfrister för sårbarhetsavisering definierade i avtalet?
• Rapporteras kritiska leverantörssårbarheter utan onödigt dröjsmål?
• Är svagheter som påverkar kunder kopplade till skyldigheter om stöd vid incidenter?
• Kan leverantören tillhandahålla underlag för åtgärdande eller säkerhetsmeddelanden?
• Förs sårbarhetsförpliktelser vidare till underleverantörer?
• Finns det en exitstrategi om åtgärdandet är otillräckligt?

Det är här NIS2, DORA och ISO/IEC 27001:2022 möts. Hantering av leverantörssårbarheter är inte en kryssruta i upphandling. Det är en del av operativ resiliens.

Underlagsmappning för ISO 27001, NIS2, DORA, GDPR och COBIT

De starkaste CVD-programmen är underlagsdrivna. De utgår från att varje betydande rapport senare kan granskas av internrevision, certifieringsrevisorer, tillsynsmyndigheter, kunder, försäkringsgivare eller styrelsens riskkommitté.

Clarysecs Policy för revision och efterlevnadsövervakning för SME Audit and Compliance Monitoring Policy - SME fångar en detalj som många team missar:

”Metadata (t.ex. vem som samlade in dem, när och från vilket system) måste dokumenteras.”
Källa: Audit and Compliance Monitoring Policy-sme, införandekrav för policyn, klausul 6.2.3

En skärmdump av en patchad server är svag om ingen vet vem som tog den, när, från vilket system och hur den mappar till sårbarheten. Ett ärende med tidsstämplar, skannerutdata, pull request, ändringsgodkännande, driftsättningsloggar, övervakningsfråga, bekräftelse från omtestning och metadata är betydligt starkare.

En mer detaljerad spårbarhetsmatris hjälper vid kunders leverantörsgranskning och internrevision.

Olika revisorer kommer att testa samma process ur olika perspektiv.

En ISO/IEC 27001:2022-revisor börjar med ISMS. Revisorn frågar om skyldigheter för sårbarhetsrapportering ingår i intressentkraven, om risker bedöms konsekvent, om kontroller finns i SoA, om operativt underlag finns och om ledningen granskar trender och försenade poster.

En DORA- eller finanssektorsgranskare fokuserar på operativ resiliens. Granskaren undersöker integrering av IKT-risk, incidentklassificering, eskalering till högsta ledningen, kundkommunikation, tredjepartsberoenden, testning och erfarenhetsåterföring. Om sårbarheten påverkar en kritisk eller viktig funktion förväntas en tydlig koppling mellan det tekniska ärendet, verksamhetspåverkan, kontinuitetskonsekvenser och leverantörsförpliktelser.

En GDPR-granskare fokuserar på personuppgifter. Var personuppgifter inblandade? Förekom obehörig åtkomst, förlust, ändring eller röjande? Var rollerna som personuppgiftsansvarig och personuppgiftsbiträde tydliga? Bedömdes tröskeln för personuppgiftsincident? Var skyddsåtgärder såsom kryptering, åtkomstkontroll, loggning och uppgiftsminimering relevanta?

En COBIT 2019- eller ISACA-revisor fokuserar på styrning, ansvarsskyldighet, prestation och assurance. Revisorn letar efter definierat ägarskap, mätetal, eskalering, kontrollmål, ledningstillsyn och undantagsuppföljning. En försenad kritisk sårbarhet är inte bara ett tekniskt problem. Det är ett styrningsproblem om den inte formellt eskaleras och riskaccepteras.

En NIST-orienterad granskare tänker i termer av Identify, Protect, Detect, Respond och Recover. Granskaren vill se tillgångsägarskap, sårbarhetsidentifiering, prioritering, skyddande ändring, detektering av exploatering, samordning av respons och validering av återställning.

Fördelen med en integrerad CVD-modell är att samma underlagsryggrad kan stödja alla dessa granskningar.

Den månatliga kontrollslingan: mätetal som ledningen kan använda

CVD slutar inte när ärendet stängs. Policy för samordnad sårbarhetsrapportering kräver löpande logggranskning:

”VRT ska föra en logg över sårbarhetsrapportering som följer varje rapport från mottagande till stängning. Loggen ska granskas månadsvis för att säkerställa att öppna poster utvecklas i rätt tid. Försenade poster ska eskaleras.”
Källa: Policy för samordnad sårbarhetsrapportering, övervakning och revision, klausul 9.1

Denna månatliga granskning gör sårbarhetsrapportering till styrelsefärdig styrning. Ledningen behöver inte varje teknisk detalj. Den behöver trend, exponering, ansvarsskyldighet och försenad risk.

I ett moget Clarysec-införande matar denna månatliga logggranskning riskregister, tillämplighetsförklaring, backlogg för säker utveckling, leverantörsgranskningar, erfarenhetsåterföring från incidenter, internrevisionsplan och rapportpaket till ledningen.

Bygg processen innan den allvarliga rapporten kommer

Den sämsta tidpunkten att utforma samordnad sårbarhetsrapportering är efter att en säkerhetsforskare har publicerat er svaghet offentligt eller en kritisk bankkund har pausat onboarding. NIS2, DORA, GDPR, ISO/IEC 27001:2022, NIST-liknande förväntningar på resiliens och COBIT 2019-styrning pekar alla i samma riktning: sårbarhetsrapportering ska planeras, ägas, testas, styrkas med underlag och förbättras.

Börja med dessa fem åtgärder:

1. Anta eller anpassa Policy för samordnad sårbarhetsrapportering.
2. Bygg mottagnings- och triageringsflödet med Zenith Blueprint, särskilt steg 13 för SoA-spårbarhet, steg 16 för rapporteringskultur, steg 19 för teknisk sårbarhetshantering och steg 23 för leverantörsavtal.
3. Mappa arbetsflödet genom Zenith Controls, med fokus på ISO/IEC 27002:2022 controls A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 och A.8.32.
4. Lägg till SME-anpassade klausuler från Incident Response Policy-sme, Vulnerability and Patch Management Policy-sme, Third-Party and Supplier Security Policy-sme, Application Security Requirements Policy-sme och Audit and Compliance Monitoring Policy-sme där proportionalitet är viktigt.
5. Genomför en skrivbordsövning som simulerar en rapport från en säkerhetsforskare som påverkar personuppgifter och en komponent som driftas av leverantör, och testa därefter bekräftelse, triage, incidentklassificering, patchning, kundkommunikation, insamling av underlag och eskalering till ledningen.

Clarysec kan hjälpa er att göra detta till en fungerande CVD-policy, ett mottagningsregister, en ISO/IEC 27001:2022-underlagskarta, ett beslutsträd för NIS2 och DORA, en modell för leverantörseskalering och ett kontrollpaket med revisionsberedskap. Målet är enkelt: när nästa sårbarhetsrapport kommer ska ert team inte improvisera. Det ska agera med förtroende, underlag och kontroll.