Revisionsklar riskbedömning enligt ISO 27001 för NIS2 och DORA

Kaffet på Sarahs skrivbord hade kallnat.

Som CISO i ett snabbväxande fintechbolag var hon van vid press. Företaget hade precis vunnit en stor bankpartner, och frågeformuläret för leverantörsgranskning på hennes skärm borde ha varit en formalitet. De första frågorna var välbekanta: tillhandahåll tillämpbarhetsförklaringen enligt ISO/IEC 27001:2022, dela det senaste riskregistret, beskriv metoden för riskbedömning.

Sedan ändrade frågeformuläret karaktär.

Visa hur ert riskhanteringsprogram hanterar DORA. Redogör för er beredskap för NIS2-direktivet, inklusive ledningens ansvar och åtgärder för risker i leveranskedjan. Tillhandahåll underlag som visar att kritiska IKT-leverantörer bedöms, övervakas och omfattas av planer för incidenthantering och verksamhetskontinuitet.

På måndag morgon låg samma fråga på dagordningen för styrelsens riskkommitté. Certifieringsrevision enligt ISO 27001 om åtta veckor. DORA-tryck från kunder i finanssektorn. NIS2-klassificeringsfrågor för en molnbaserad tjänst som expanderade inom EU. Inköp sade att leverantörsgranskningar fanns, men att underlaget var utspritt i e-post, avtalsmappar och ett leverantörskalkylblad. Juridik sade att den regulatoriska mappningen fortfarande pågick. Teknikorganisationen sade att riskregistret i stort sett var klart.

Styrelsen ställde den enda fråga som betydde något:

Kan vi bevisa att vår riskbedömning och riskbehandlingsplan är tillräckliga?

Det är den verkliga utmaningen för SaaS-, fintech-, leverantörer av hanterade tjänster, moln- och digitala plattformsföretag. Inte om det finns ett riskregister. Inte om kontroller i bilaga A har kopierats in i ett kalkylblad. Frågan är om organisationen, under revisions- och kundtryck, kan visa att dess process för riskbedömning enligt ISO 27001 är repeterbar, riskbaserad, godkänd av riskägare, kopplad till behandlingsåtgärder, mappad mot rättsliga skyldigheter och levande i den operativa verksamheten.

Rätt genomförd kan en riskbedömning och en riskbehandlingsplan enligt ISO 27001 stödja certifiering enligt ISO/IEC 27001:2022, NIS2 Article 21 om riskhanteringsåtgärder för cybersäkerhet, DORA-krav på IKT-riskhantering, GDPR-ansvarsskyldighet, leverantörssäkring, incidentberedskap och styrelserapportering.

Fel genomförd blir den ett kalkylblad som revisorer plockar isär på trettio minuter.

Den här guiden visar hur Clarysec bygger revisionsklart underlag för riskbedömning och riskbehandling enligt ISO 27001 med hjälp av Zenith Blueprint: revisorns 30-stegsplan, Clarysecs policyer och Zenith Controls: vägledning för korsvis efterlevnad.

Varför riskbedömning enligt ISO 27001 nu är ett nav för efterlevnad

EU:s regulatoriska landskap konvergerar kring en enkel princip: cybersäkerhetsrisk ska styras, dokumenteras, testas och ägas.

ISO/IEC 27001:2022 fungerar redan på det sättet. Klausulerna 4.1 till 4.4 kräver att organisationen förstår sitt sammanhang, intressenter, ISMS-omfattning och processernas samverkan innan risk bedöms. Klausulerna 6.1.2 och 6.1.3 kräver en definierad process för riskbedömning och riskbehandling inom informationssäkerhet. Klausulerna 8.2 och 8.3 kräver att organisationen genomför riskbedömningar och genomför riskbehandlingsplanen, samtidigt som dokumenterad information bevaras.

NIS2 och DORA gör samma riskbaserade logik mer brådskande.

NIS2 Article 20 kräver att ledningsorgan i väsentliga och viktiga entiteter godkänner riskhanteringsåtgärder för cybersäkerhet, utövar tillsyn över genomförandet och genomgår cybersäkerhetsutbildning. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för att hantera risker för nätverks- och informationssystem. Dessa åtgärder omfattar riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, sårbarhetshantering, effektivitetsmått, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering och flerfaktorsautentisering eller säker kommunikation där det är lämpligt.

DORA skapar liknande tryck på finansiella entiteter. Articles 5 och 6 kräver att ledningsorganet definierar, godkänner, övervakar och fortsatt ansvarar för arrangemang för IKT-riskhantering. DORA förväntar sig ett dokumenterat ramverk för IKT-riskhantering som är integrerat i den övergripande riskhanteringen och understöds av policyer, rutiner, protokoll, verktyg, internrevision, avhjälpande åtgärder, kontinuitet, testning, incidenthantering och tredjepartsstyrning inom IKT.

Slutsatsen är praktisk och oundviklig: riskregistret är inte längre ett arbetsblad för det tekniska teamet. Det är styrningsunderlag.

Clarysecs Enterprise Riskhanteringspolicy gör denna förväntan explicit:

En formell riskhanteringsprocess ska upprätthållas i enlighet med ISO/IEC 27005 och ISO 31000 och omfatta riskidentifiering, riskanalys, riskutvärdering, riskbehandling, riskövervakning och riskkommunikation.

Från Enterprise Riskhanteringspolicy, avsnittet ”Styrningskrav”, policyklausul 5.1.

Samma policy definierar det revisionsklara resultatet:

Att upprätthålla ett centraliserat, versionshanterat riskregister och en riskbehandlingsplan som återspeglar aktuell riskstatus, kontrolltäckning och framdrift i riskreducering.

Från Enterprise Riskhanteringspolicy, avsnittet ”Mål”, policyklausul 3.3.

Den formuleringen, ”aktuell riskstatus, kontrolltäckning och framdrift i riskreducering”, är skillnaden mellan en statisk efterlevnadsfil och ett försvarbart riskprogram.

Börja med omfattning, skyldigheter och riskkriterier

Många svaga riskbedömningar enligt ISO 27001 börjar med en kontrollchecklista. Det är fel ordning.

ISO 27001 kräver att organisationen fastställer sammanhang, krav från intressenter, ISMS-omfattning, ledarskapsansvar och riskplanering innan kontroller väljs. ISO/IEC 27005:2022 förstärker detta genom att rekommendera att organisationer identifierar intressenternas grundläggande krav innan risk bedöms. Dessa krav kan komma från ISO-standarder, sektorsreglering, nationell lagstiftning, kundavtal, interna policyer, tidigare riskbehandlingsaktiviteter och leverantörsskyldigheter.

För ett SaaS- eller fintechbolag riktat mot EU bör riskprocessen börja med en inventering av efterlevnadskrav och skyldigheter.

För små och medelstora företag anger Clarysecs Policy för rättslig och regulatorisk efterlevnad - SME utgångspunkten:

GM måste upprätthålla ett enkelt, strukturerat register över regelefterlevnadskrav som listar:

Från SME Policy för rättslig och regulatorisk efterlevnad, avsnittet ”Styrningskrav”, policyklausul 5.1.1.

Det enkla registret är en brygga mellan regelefterlevnad och riskhantering. Om det anger att GDPR är tillämpligt eftersom EU-personuppgifter behandlas, att NIS2 kan vara tillämpligt eftersom organisationen tillhandahåller digitala eller hanterade tjänster, eller att DORA är relevant genom kunder i finanssektorn, ska dessa skyldigheter påverka riskkriterier och behandlingsprioriteringar.

Zenith Blueprint är tydlig på denna punkt i riskhanteringsfasen, steg 10, ”Fastställande av riskkriterier och konsekvensmatris”:

Beakta även rättsliga/regulatoriska krav i era acceptanskriterier. Vissa risker kan vara oacceptabla oavsett sannolikhet på grund av lagkrav.

Från Zenith Blueprint, riskhanteringsfasen, steg 10.

Den ger även en praktisk regel för workshoppar:

”Varje risk som kan leda till bristande efterlevnad av tillämpliga lagar (GDPR osv.) är inte acceptabel och måste reduceras.”

Från Zenith Blueprint, riskhanteringsfasen, steg 10.

För Sarahs fintechbolag förändrar detta poängsättningsmodellen. En sårbarhet i en leverantörs API kan ha låg sannolikhet, men om ett utnyttjande kan utlösa en större DORA-relaterad IKT-incident, en betydande NIS2-incident, en GDPR-bedömning av personuppgiftsincident, ett brott mot kund-SLA eller eskalering till styrelsen, är konsekvensen hög eller kritisk. Exponering mot efterlevnadskrav blir en del av risklogiken, inte ett separat kalkylblad.

Bygg ett riskregister som revisorer kan testa

Revisorer frågar inte bara vilka era största risker är. De testar om metoden är definierad, repeterbar, spårbar och tillämpad.

De kommer att fråga:

• Hur identifierade ni dessa risker?
• Vilka tillgångar, tjänster, leverantörer, datatyper och processer ingick i omfattningen?
• Vilka kriterier användes för sannolikhet och konsekvens?
• Vem äger varje risk?
• Vilka befintliga kontroller reducerar risken?
• Varför valdes behandlingsbeslutet?
• Var finns underlaget som visar att behandlingen har genomförts?
• Vem godkände den kvarstående risken?
• När ska risken omprövas?

Clarysecs Riskhanteringspolicy - SME fångar den minsta revisionsklara riskposten:

Varje riskpost måste innehålla: beskrivning, sannolikhet, konsekvens, poäng, ägare och riskbehandlingsplan.

Från SME Riskhanteringspolicy, avsnittet ”Styrningskrav”, policyklausul 5.1.2.

För enterpriseprogram utökar Zenith Blueprint strukturen i riskhanteringsfasen, steg 11, ”Bygga och dokumentera riskregistret”. Den rekommenderar kolumner som Risk-ID, tillgång, hot, sårbarhet, riskbeskrivning, sannolikhet, konsekvens, risknivå, befintliga kontroller, riskägare, behandlingsbeslut, riskbehandlingsplan eller kontroller samt status.

En stark riskpost ser ut så här:

Detta är väsentligt annorlunda än ”tredjepartsrisk, hög, reducera”. Den revisionsklara versionen kopplar samman tillgång, hot, sårbarhet, konsekvens, befintliga kontroller, ägare, reglering, underlag och styrning.

Gör riskbehandling till en underlagsplan

En riskbehandlingsplan ska besvara fyra operativa frågor:

1. Vad ska vi göra?
2. Vem äger åtgärden?
3. När ska den vara klar?
4. Hur ska vi bevisa att den har reducerat risken?

ISO/IEC 27001:2022 Clause 6.1.3 kräver att organisationen väljer behandlingsalternativ, fastställer nödvändiga kontroller, jämför dem med bilaga A för att undvika utelämnanden, tar fram en tillämpbarhetsförklaring, formulerar en riskbehandlingsplan och inhämtar riskägarens godkännande av planen och kvarstående risker. Clause 8.3 kräver därefter genomförande av riskbehandlingsplanen och bevarad dokumenterad information om resultaten.

Enterprise Riskhanteringspolicy gör detta praktiskt:

Riskansvarig ska säkerställa att behandlingar är realistiska, tidsbegränsade och mappade mot ISO/IEC 27001-kontroller i bilaga A.

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

SME-policyn klargör också att acceptans inte är en genväg:

Acceptera: Motivera varför ingen ytterligare åtgärd krävs och registrera den kvarstående risken.

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

Acceptans måste motiveras mot kriterier, godkännas av rätt ägare och övervakas. Enligt NIS2 och DORA kan icke godkänd kvarstående risk bli ett styrningsmisslyckande.

En komplett behandlingsplan bör innehålla dessa fält:

För Sarahs R-042 blir behandlingsplanen en åtgärdslista för korsvis efterlevnad.

Planen är stark eftersom den skapar en direkt linje från ett riskscenario till ISO 27001-kontroller, NIS2-skyldigheter, DORA-artiklar, ägare och underlag.

Låt tillämpbarhetsförklaringen göra mer arbete

Tillämpbarhetsförklaringen behandlas ofta som en certifieringsartefakt. Den bör vara mer än så.

ISO/IEC 27001:2022 Clause 6.1.3 kräver att SoA omfattar nödvändiga kontroller, motivering för inkludering, genomförandestatus och motivering för undantag. Vägledningen i ISO/IEC 27005:2022 förstärker behovet av att jämföra valda kontroller med ISO/IEC 27001 bilaga A för att undvika utelämnanden.

I ett revisionsklart program blir SoA bryggan mellan riskbehandling och underlag för korsvis efterlevnad. Om en riskbehandlingsplan kräver MFA, loggning, leverantörsövervakning, återställning av säkerhetskopior, säker utveckling, incidenteskalering eller planering för exit från molntjänster bör SoA visa att relevanta kontroller i bilaga A är inkluderade, motiverade, genomförda eller planerade samt styrkta med underlag.

Det hjälper också till att undvika ett vanligt revisionsfel: riskregistret säger en sak, riskbehandlingsplanen en annan och SoA är tyst. När dessa artefakter inte stämmer överens tappar revisorer snabbt förtroendet.

Mappa riskbehandling enligt ISO 27001 mot NIS2, DORA och GDPR

ISO 27001 ersätter inte NIS2, DORA eller GDPR. Den ger en strukturerad mekanism för att ta fram underlag för dem.

Nyckeln är att bygga in mappning i riskprocessen i stället för att lägga till den i efterhand.

Denna mappning är särskilt viktig där regelverk överlappar. DORA är det sektorsspecifika ramverket för digital operativ resiliens för många finansiella entiteter, medan NIS2 kan vara direkt relevant för vissa leverantörer, samordning eller entiteter utanför DORA:s omfattning. Ett fintechbolag kan behöva DORA som sitt primära ramverk för IKT-resiliens, medan en leverantör av hanterade tjänster som stödjer fintechbolaget kan omfattas direkt av NIS2-skyldigheter.

Riskregistret måste kunna visa båda sidor av det beroendet.

Använd Zenith Controls som kompass för korsvis efterlevnad

Clarysec använder Zenith Controls som vägledning för korsvis efterlevnad för att förhindra det vanliga felet där ISO-kontroller, regulatoriska artiklar och revisionsfrågor lever i separata universum. Det skapar inte ett separat kontrollramverk. Det mappar kontrollområden i ISO/IEC 27001:2022 och ISO/IEC 27002:2022 mot andra standarder, revisionsförväntningar och efterlevnadsperspektiv.

För riskbedömning och riskbehandling enligt ISO 27001 är dessa referenser särskilt viktiga:

Lärdomen för korsvis efterlevnad är enkel. Om rättsliga skyldigheter inte finns i riskbedömningsmetoden är poängsättningen ofullständig. Om poängsättningen är ofullständig kan behandlingsprioriteringar bli fel. Om prioriteringarna är fel blir SoA och styrelserapportering opålitliga.

Zenith Blueprint gör samma poäng i riskhanteringsfasen, steg 14, ”Policyer för riskbehandling och regulatoriska korsreferenser”. Den rekommenderar att organisationer skapar en mappningstabell som listar viktiga regulatoriska säkerhetskrav och motsvarande kontroller eller policyer i ISMS. Detta är inte obligatoriskt för ISO 27001-certifiering, men det är mycket användbart för att visa att säkerhet hanteras i ett rättsligt och avtalsmässigt sammanhang.

Vad olika revisorer kommer att fråga

En certifieringsrevisor, NIS2-granskare, DORA-orienterad kund, GDPR-granskare, NIST-bedömare eller COBIT-praktiker kan granska samma underlag men ställa olika frågor.

Därför är underlagsarkitektur viktig. Samma riskpost bör vara spårbar från verksamhetsmål till tillgång, hot, sårbarhet, kontroll, ägare, regulatorisk drivkraft, behandlingsåtgärd, testresultat och ledningsbeslut.

Clarysecs policyer är utformade för att stödja den arkitekturen. Enterprise Riskhanteringspolicy anger under avsnittet ”Referensstandarder och ramverk”:

Article 5: Kräver ett dokumenterat ramverk för IKT-riskhantering, fullt täckt av denna policys struktur, inklusive SoA-mappning och KRI:er.

Detta gör policyn från ett statiskt dokument till revisionsunderlag som visar att IKT-riskstyrningen avsiktligt har utformats med DORA i åtanke.

Vanliga iakttagelser som bryter riskprogram

När Clarysec granskar underlag för riskbedömning och riskbehandling enligt ISO 27001 återkommer samma iakttagelser.

För det första ignorerar riskkriterier rättslig, regulatorisk, avtalsmässig, leverantörsrelaterad och integritetsrelaterad konsekvens. Det leder till svag poängsättning. En personuppgiftsincident eller ett kritiskt leverantörsfel kan klassas som medel eftersom sannolikheten är låg, trots att påverkan enligt GDPR, NIS2, DORA eller kundkrav bör göra den hög eller kritisk.

För det andra är riskägare generiska. ”IT” är inte en riskägare. En riskägare bör vara en roll eller person som ansvarar för behandlingsbeslut, budget, tidsplan och kvarstående risk.

För det tredje är behandlingsplaner inte tidsbegränsade. ”Förbättra övervakning” är inte en plan. ”Driftsätt larm för privilegierade sessioner i SIEM för administratörskonton i produktion senast 30 juni, ägs av SOC-chefen, testas genom simulerad administratörsinloggning och bifogat larmunderlag” är en plan.

För det fjärde är SoA frikopplad från behandlingen. Om riskbehandlingsplanen kräver leverantörsövervakning, testning av säkerhetskopiering, incidenteskalering, MFA eller loggning bör SoA återspegla relevanta kontroller och genomförandestatus.

För det femte är kvarstående risk inte godkänd. ISO 27001 kräver riskägarens godkännande av riskbehandlingsplanen och kvarstående risker. NIS2 och DORA gör detta ännu viktigare eftersom ledningens ansvar är uttryckligt.

För det sjätte behandlas leverantörsrisk som inköpsadministration. Enligt NIS2 Article 21(2)(d) och DORA Articles 28 och 30 måste leverantörs- och IKT-tredjepartsrisk vara en del av riskhanteringen, inte ett årligt frågeformulär som lagras isolerat.

För det sjunde saknas underlag för effektivitet. ISO 27001 Clause 6.1.1 kräver att planerade åtgärder utvärderas avseende effektivitet. NIS2 inkluderar effektivitetsmått i Article 21(2)(f). DORA förväntar sig testning och avhjälpande åtgärder. En kontroll som finns men aldrig testas är svagt underlag.

SME Riskhanteringspolicy - SME anger förväntan tydligt:

General Manager och riskkoordinatorn måste säkerställa att riskhanteringsaktiviteter är revisionsklara. Riskregistret och relaterade åtgärder omfattas av intern och extern revision.

Från SME Riskhanteringspolicy, avsnittet ”Efterlevnad och tillämpning”, policyklausul 8.2.1.

Styrelserapportering utan att dränka ledningen

NIS2, DORA och ISO 27001 pekar alla mot ledningens ansvar, men styrelser behöver inte varje riskrad. De behöver rapportering som stödjer beslut.

Ett bra riskpaket till styrelsen bör visa:

• Höga och kritiska risker per område
• Försenade behandlingsåtgärder
• Regulatoriska risker som rör NIS2, DORA, GDPR eller avtal
• Leverantörsrisker som påverkar kritiska eller viktiga tjänster
• Incidenttrender och trender för nära händelser
• Kvarstående risker som inväntar acceptans
• Testresultat för kontrolleffektivitet
• Väsentliga ändringar i omfattning, leverantörer, teknik eller lagstiftning
• Internrevisionsiakttagelser och korrigerande åtgärder

Clarysec rekommenderar vanligtvis månatliga operativa riskgranskningar och kvartalsvisa ledningsgenomgångar. Månatliga granskningar fokuserar på leverans av behandlingsåtgärder. Kvartalsvisa granskningar fokuserar på acceptans, finansiering, prioritering, regulatorisk exponering och strategiska riskbeslut.

Denna rytm stödjer också ständig förbättring. Riskbedömningar bör uppdateras när incidenter inträffar, sårbarheter uppstår, nya tillgångar införs, teknik ändras, leverantörer byts, lagar ändras, kundskyldigheter förändras eller riskaptit ändras.

Clarysecs genomförandeväg

Ett samlat riskprogram undviker frånkopplade kalkylblad för ISO, NIS2, DORA, GDPR och kundförsäkran. Den praktiska vägen är:

1. Bekräfta ISMS-omfattning, tjänster, tillgångar, leverantörer, jurisdiktioner och kundskyldigheter.
2. Bygg eller uppdatera registret över regelefterlevnadskrav med hjälp av Policy för rättslig och regulatorisk efterlevnad - SME där det är lämpligt.
3. Definiera riskmetodik, acceptanskriterier, sannolikhetsskalor, konsekvensskalor och regler för regulatorisk konsekvens.
4. Bygg riskregistret med hjälp av riskhanteringsfasen i Zenith Blueprint och Clarysecs metod för Riskregister och SoA Builder.
5. Identifiera tillgångsbaserade och scenariobaserade risker, inklusive scenarier för leverantör, moln, integritet, kontinuitet, incident, sårbarhet, säker utveckling och åtkomst.
6. Poängsätt risker med kriterier som omfattar rättslig, regulatorisk, avtalsmässig, operativ, integritetsrelaterad, leverantörsrelaterad och finansiell konsekvens.
7. Välj behandlingsalternativ: reducera, undvika, överföra eller acceptera.
8. Mappa nödvändiga kontroller mot ISO/IEC 27001:2022 bilaga A och vägledningen i ISO/IEC 27002:2022.
9. Skapa eller uppdatera tillämpbarhetsförklaringen.
10. Mappa behandlingar mot NIS2 Article 21, DORA:s IKT-riskhantering och tredjepartsförväntningar, GDPR-ansvarsskyldighet och kunders avtalsförpliktelser.
11. Samla underlag, validera kontrolleffektivitet och inhämta godkännande av kvarstående risk.
12. Förbered ett revisionspaket organiserat efter risk, kontroll, regelverk och underlagsartefakt.
13. För in resultaten i ledningens genomgång, internrevision, korrigerande åtgärder och ständig förbättring.

Detta är inte pappersarbete för sin egen skull. Det är operativsystemet för försvarbar cyberstyrning.

Bygg ett revisionsklart riskbehandlingspaket

Sarahs berättelse slutar väl eftersom hon slutade behandla ISO 27001, NIS2 och DORA som separata efterlevnadsprojekt. Hon använde riskbedömningen enligt ISO 27001 som den centrala motorn, byggde in regulatoriska skyldigheter i riskkriterierna, mappade behandlingsåtgärder mot bilaga A och EU-krav och samlade underlag som kunder, revisorer och styrelsen kunde förstå.

Er organisation kan göra samma sak.

Använd Zenith Blueprint: revisorns 30-stegsplan för att definiera riskkriterier, bygga riskregistret, skapa riskbehandlingsplanen och korsreferera regulatoriska krav.

Använd Zenith Controls: vägledning för korsvis efterlevnad för att koppla kontrollområden i ISO/IEC 27001:2022 bilaga A till styrning, efterlevnad av rättsliga krav, säkerhetsförsäkran och revisionsperspektiv.

Använd Clarysecs Riskhanteringspolicy, Riskhanteringspolicy - SME och Policy för rättslig och regulatorisk efterlevnad - SME för att standardisera ägarskap, register, behandlingsbeslut och revisionsklart underlag.

Det snabbaste praktiska nästa steget är att ta era tio största risker och testa dem mot fem frågor:

1. Är den regulatoriska konsekvensen synlig?
2. Är riskbehandlingsplanen tidsbegränsad och ägd?
3. Är varje behandling mappad mot bilaga A och SoA?
4. Är relevans för NIS2, DORA, GDPR eller kund dokumenterad där det är tillämpligt?
5. Finns det underlag som visar att kontrollen fungerar?

Om svaret är nej kan Clarysec hjälpa er att omvandla riskregistret till ett försvarbart riskbehandlingsprogram för korsvis efterlevnad som revisorer, tillsynsmyndigheter, kunder och styrelser kan lita på.