Beredskap för EU:s cybersolidaritetsakt med ISO 27001

03:17-incidenten som gör EU-samverkan till en revisionsfråga

Klockan 03:17 en tisdagsmorgon stirrar Maria, informationssäkerhetschef på InnovateCloud, på en skärm full av larm. Hennes företag är en medelstor europeisk SaaS-leverantör som betjänar logistikkunder i Tyskland, Frankrike och Polen. Det första larmet ser ut som misstänkt privilegierad åtkomst i en produktionskundmiljö. Tio minuter senare rapporterar leverantören av hanterade säkerhetstjänster liknande aktivitet som påverkar två andra kunder. Klockan 04:00 ser SOC API-anrop från infrastruktur som tidigare har kopplats till förberedelser för ransomwareangrepp.

InnovateCloud var inte det ursprungliga målet. En central infrastrukturleverantör verkar ingå i skadeområdet. Konsekvensen är dock nu Marias problem.

En berörd kund är en tysk bank som begär svar enligt DORA. En annan är en kritisk leverantör inom energisektorn som redan är klassificerad enligt nationella NIS2-regler. Miljön kan innehålla personuppgifter, men exfiltration är ännu inte bekräftad. Säkerhetsteamet vill begränsa hotet omedelbart. Juridik vill veta om NIS2:s 24-timmarsfrist för tidig varning har börjat löpa. Dataskyddsombudet frågar om anmälan av personuppgiftsincident enligt GDPR kan bli aktuell. Styrelsen vill veta om störningen kan spridas över flera medlemsstater.

År 2026 är detta inte längre bara en intern kris.

EU:s cybersolidaritetsakt förändrar den operativa verkligheten för storskaliga och gränsöverskridande cyberincidenter. Den inför mekanismer på EU-nivå för detektering, beredskap och respons, inklusive det europeiska cybersäkerhetsvarningssystemet, cybersäkerhetskrismekanismen och EU:s cybersäkerhetsreserv. Även om en organisation aldrig direkt begär stöd från reserven kan dess underlag, myndighetskontakter, leverantörsavtal, incidenttidslinjer och kundkommunikation bli en del av en bredare europeisk responskedja.

Gapet blir snabbt synligt. Många organisationer har verktyg, ärenden och policyer, men saknar underlag som håller för regulatorisk granskning. De kan säga ”vi kontaktade tillsynsmyndigheten”, men kan inte visa vem som var behörig, vilket tröskelvärde som utlöste kontakten, vad som kommunicerades, om loggar bevarades, om en leverantör var avtalsmässigt skyldig att bistå eller om en slutrapport kan återskapas från beslut som dokumenterades i realtid.

Svaret är inte ännu en isolerad ”Cyber Solidarity Act-pärm”. Svaret är ett ledningssystem för informationssäkerhet (ISMS) enligt ISO/IEC 27001:2022 som skapar underlag en gång och återanvänder det för förväntningar enligt NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019.

Det underlaget börjar före incidenten.

Varför EU:s cybersolidaritetsakt höjer kraven på underlag

Cyber Solidarity Act är utformad för cyberdetektering, beredskap och krishantering på EU-nivå. Den praktiska effekten för CISO:er, revisorer och complianceansvariga är tydlig: samordning av storskaliga incidenter kräver underlag som är snabbare, tydligare, mer konsekvent och enklare att dela med betrodda intressenter.

När gränsöverskridande påverkan är möjlig kan en organisation behöva samordna med nationella CSIRT:er, behöriga myndigheter, sektortillsynsmyndigheter, dataskyddsmyndigheter, finansiella tillsynsmyndigheter, brottsbekämpande myndigheter, kunder, personuppgiftsbiträden, leverantörer och externa incidenthanterare. EU:s cybersäkerhetsreserv tillför ytterligare en dimension eftersom förhandsgranskade privata leverantörer kan stödja beredskap, respons och återställning. Det gör leverantörsstyrning, rättslig befogenhet, datahantering och bevarande av underlag ännu viktigare.

Privata aktörer står i centrum för denna verklighet. Molnleverantörer, datacenter, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, operatörer av digital infrastruktur, fintechbolag och SaaS-plattformar innehar ofta den telemetri, de loggar, de uppgifter om kundpåverkan och de tekniska fakta som myndigheter behöver för att förstå en större incident.

NIS2 pekar redan i den riktningen. Det gäller många medelstora och stora entiteter i sektorer enligt bilaga I och bilaga II som tillhandahåller tjänster eller bedriver verksamhet i EU. Det omfattar även vissa entiteter oavsett storlek, inklusive tillhandahållare av betrodda tjänster, DNS-tjänsteleverantörer, toppdomänregister och leverantörer av domännamnsregistreringstjänster. Bilaga I omfattar digital infrastruktur såsom molntjänster, datacentertjänster, innehållsleveransnätverk, DNS-leverantörer, tillhandahållare av betrodda tjänster och TLD-register. Den omfattar även IKT-tjänstehantering B2B, inklusive leverantörer av hanterade tjänster och leverantörer av hanterade säkerhetstjänster. Bilaga II omfattar digitala leverantörer såsom internetbaserade marknadsplatser, sökmotorer online och plattformar för sociala nätverkstjänster.

DORA lägger till ett andra lager för den finansiella sektorn. Sedan den 17 januari 2025 gäller den för ett brett spektrum av finansiella entiteter, inklusive kreditinstitut, betalningsinstitut, institut för elektroniska pengar, värdepappersföretag, leverantörer av kryptotillgångstjänster, handelsplatser, försäkrings- och återförsäkringsföretag, kreditvärderingsinstitut, leverantörer av gräsrotsfinansieringstjänster med flera. Den skapar också betydande förväntningar på IKT-tredjepartstjänsteleverantörer eftersom finansiella entiteter fortsatt ansvarar för outsourcade IKT-tjänster.

En fintechincident under 2026 kan därför samordnas genom DORA:s tillsynskanaler, samtidigt som SaaS-leverantören eller MSSP:n som stödjer fintechbolaget kan omfattas av NIS2. Samma tekniska händelse kan skapa olika rapporteringsskyldigheter, underlagskrav och avtalsförpliktelser för olika aktörer.

ISO/IEC 27001:2022 ger organisationer operativt stöd för att hantera denna komplexitet. Klausulerna 4.1 till 4.4 kräver att organisationen definierar sitt ISMS i verksamhetssammanhanget, identifierar intressenter och deras rättsliga, regulatoriska och avtalsmässiga krav, definierar gränser och beroenden samt etablerar ledningssystemet. Klausulerna 5.1 till 5.3 gör ledningen ansvarig för policy, resurser, integrering och rolltilldelning. Klausulerna 6.1.1 till 6.1.3 kräver upprepbar riskbedömning, riskbehandling och en Statement of Applicability. Klausul 8.1 kräver operativ styrning, inklusive styrning av externt tillhandahållna processer, produkter och tjänster.

Detta är kärnan i beredskap för Cyber Solidarity Act: att visa att krishanteringen är styrd, testad och möjlig att granska, inte improviserad.

Clarysecs underlagsmodell: en incident, många skyldigheter

En gränsöverskridande incident väntar inte medan juridiska team klassificerar den. Underlag måste fångas från det första larmet och därefter styras till rätt rapporterings- och samordningsspår.

Clarysecs arbetssätt kopplar samman tre tillgångar:

1. Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, som omvandlar införandet av ISO/IEC 27001:2022 till en sekvenserad och revisionsförberedd resa.
2. Zenith Controls: The Cross-Compliance Guide Zenith Controls, som mappar ISO/IEC 27002:2022-kontroller till relaterade kontroller, attribut, operativa förmågor, säkerhetsdomäner och förväntningar på underlag över flera ramverk.
3. Clarysecs policymallar för incidenthantering, bevisinsamling, leverantörssäkerhet, loggning, övervakning och verksamhetskontinuitet, anpassade för enterprise- och SME-miljöer.

I Zenith Blueprint, fasen Controls in Action, behandlar steg 22 ISO/IEC 27002:2022-kontroll 5.5, kontakt med myndigheter. Där anges följande:

Kontroll 5.5 säkerställer att en organisation är förberedd på att samverka med externa myndigheter när det behövs, inte reaktivt eller under panik, utan genom fördefinierade, strukturerade och väl kända kanaler.

Samma avsnitt ställer frågan varje CISO bör besvara före krisen:

Om er organisation skulle bli måltavla för en cyberattack, bli inblandad i en personuppgiftsincident eller omfattas av en utredning, vem skulle då ringa myndigheterna? Hur skulle de veta vad de ska säga? Under vilka förutsättningar skulle sådan kontakt initieras?

Det är inte administrativt pappersarbete. I en miljö präglad av Cyber Solidarity Act är det skillnaden mellan en kontrollerad tidig varning och motstridiga budskap i flera jurisdiktioner.

Zenith Controls behandlar ISO/IEC 27002:2022-kontroll 5.5, kontakt med myndigheter, som förebyggande och korrigerande, kopplad till konfidentialitet, riktighet och tillgänglighet, och anpassad till begreppen identifiera, skydda, respondera och återställa. Den kopplar 5.5 till planering och förberedelser för incidenthantering, händelserapportering, hotinformation, särskilda intressegrupper och incidenthantering.

Samma guide behandlar ISO/IEC 27002:2022-kontroll 5.24, planering och förberedelser för hantering av informationssäkerhetsincidenter, som en korrigerande kontroll kopplad till respondera och återställa. Kopplingarna till händelsebedömning, incidenthantering, erfarenhetsåterföring, loggning, övervakning, säkerhet under störning och kontinuitet visar vad revisorer ofta testar: om planen kopplar samman detektering, klassificering, eskalering, underlag, återställning och lärande.

För hantering av underlag är ISO/IEC 27002:2022-kontroll 5.28, insamling av bevisning, särskilt viktig. Zenith Controls kopplar den till incidenthantering, loggning, övervakning och händelserapportering. I en allvarlig gränsöverskridande incident är det här den tekniska utredningen blir försvarbar.

Mappa beredskap för Cyber Solidarity Act till ISO 27001-underlag

EU:s cybersolidaritetsakt skapar en miljö för beredskap och samordning. ISO/IEC 27001:2022 tillhandahåller underlagsmotorn. NIS2, DORA och GDPR definierar många specifika förväntningar på rapportering, styrning och skydd.

Notera vad som saknas: en separat efterlevnadssilo. Samma underlag som stödjer ISO/IEC 27001:2022-certifiering kan stödja NIS2:s ledningsansvar, DORA:s IKT-riskhantering, GDPR:s ansvarsskyldighet för säkerhet, NIST CSF:s kommunikationsresultat och COBIT 2019:s förväntningar på kontrollsäkring.

NIS2: rapporteringsklockan startar när kännedom uppstår

NIS2 är centralt för beredskap 2026 eftersom det definierar ett stegvis arbetsflöde för incidentrapportering.

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 betydande incidenter som påverkar tjänsteleveransen. Den tidiga varningen ska lämnas utan onödigt dröjsmål och senast 24 timmar efter att organisationen fått kännedom om den betydande incidenten. Den bör, där det är tillämpligt, ange om skadliga eller olagliga handlingar misstänks och om gränsöverskridande påverkan är möjlig.

En incidentanmälan följer utan onödigt dröjsmål och senast 72 timmar efter kännedom, uppdaterar den tidiga varningen och ger en inledande bedömning av allvarlighetsgrad, påverkan och tillgängliga indikatorer på kompromettering. En slutrapport ska lämnas inom en månad efter incidentanmälan, med allvarlighetsgrad, påverkan, sannolik hottyp eller rotorsak, riskbegränsande åtgärder och gränsöverskridande påverkan.

Det är därför incidenthantering inte kan börja med ett tomt dokument.

Enterprise-versionen av Incidenthanteringspolicy Incidenthanteringspolicy anger:

NIS2 Article 23 (avisering inom 24 timmar från att organisationen fått kännedom om incidenten)

SME-versionen Incident Response Policy - SME Incident Response Policy - SME för in samma tidslogik i praktisk styrning:

”Tidslinjer för respons, inklusive dataåterställning och aviseringsskyldigheter, måste dokumenteras och anpassas till rättsliga krav, såsom GDPR:s krav på anmälan av personuppgiftsincident inom 72 timmar.”

Från Incident Response Policy - SME, avsnittet ”Styrningskrav”, klausul 5.3.2.

Den tvingar också in bedömningen över flera regelverk i incidentprocessen:

”När kunddata berörs måste verkställande direktör bedöma rättsliga aviseringsskyldigheter baserat på tillämpligheten av GDPR, NIS2 eller DORA.”

Från Incident Response Policy - SME, avsnittet ”Riskbehandling och undantag”, klausul 7.4.1.

I ett Cyber Solidarity Act-scenario blir ”gränsöverskridande påverkan är möjlig” operativt viktigt. Den tidiga varningen har kanske inte fullständiga fakta, men organisationen måste kunna visa varför den misstänkte eller inte misstänkte gränsöverskridande påverkan baserat på tillgängligt underlag.

Incidentposten bör fånga:

• När organisationen fick kännedom.
• Vem som klassificerade händelsen som en potentiell incident.
• Vilka tjänster, länder, kunder eller sektorer som potentiellt påverkades.
• Om skadlig eller olaglig aktivitet misstänktes.
• Vilka indikatorer på kompromettering som fanns tillgängliga.
• Vilken kontaktväg till myndighet som användes.
• Om kundkommunikation krävdes.
• Vilket underlag som bevarades före större avhjälpande åtgärder.

Den bästa tiden att utforma dessa fält är före 03:17.

DORA: när kunden är reglerad men leverantören har loggarna

DORA förändrar leverantörsdialogen. Finansiella entiteter måste hantera IKT-tredjepartsrisk som en del av sitt ramverk för IKT-riskhantering. Outsourcing av IKT-tjänster överför inte det regulatoriska ansvaret från den finansiella entiteten.

DORA kräver strategier för IKT-tredjepartsrisk, register över IKT-tjänsteavtal, leverantörsgranskning, planering av revision och inspektion, rätt att säga upp avtalet samt testade exitstrategier för kritiska eller viktiga IKT-tjänster. Article 30 kräver avtalsmässig tydlighet, inklusive tjänstebeskrivningar, platser, datahantering, konfidentialitet, riktighet, tillgänglighet, servicenivåer, assistans vid IKT-incidenter, samarbete med myndigheter och rätt att säga upp avtalet. För kritiska eller viktiga funktioner gäller striktare villkor.

Återvänd till Marias incident. Den tyska banken regleras av DORA. InnovateCloud tillhandahåller SaaS-tjänster. MSSP:n detekterar misstänkt aktivitet. Molninfrastrukturleverantören har några av de centrala revisionsloggarna. En underleverantör driver en del av telemetripipelinen. Banken är fortsatt ansvarig, men den kan inte klassificera och rapportera korrekt utan leverantörsunderlag.

Clarysec hanterar detta genom leverantörsklassificering och avtalsunderlag. Enterprise-versionen av Policy för leverantörssäkerhet och tredjepartssäkerhet Policy för leverantörssäkerhet och tredjepartssäkerhet kräver:

Avtal med leverantörer måste innehålla:

SME-versionen Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME använder samma efterlevnadslogik i en lättare operativ modell:

Avtal måste innehålla obligatoriska klausuler som omfattar:

Värdet ligger i schemat bakom dessa ord: skyldigheter för incidentavisering, åtkomst till loggar, revisionsrätt, sekretess, dataplats, kontroller av underleverantörer, samarbete med myndigheter, återställningsstöd och exit-skyldigheter.

Zenith Blueprint, fasen Controls in Action, steg 23, ger införandevägen:

Sammanställ en fullständig lista över nuvarande leverantörer och tjänsteleverantörer (5.19) och klassificera dem baserat på åtkomst till system, data eller operativ kontroll. För varje klassificerad leverantör ska ni verifiera att säkerhets- förväntningar är tydligt inarbetade i avtal (5.20), inklusive konfidentialitet, åtkomst, incidentrapportering och krav på regelefterlevnad.

Den fortsätter med nedströmsrisk:

För varje kritisk leverantör, identifiera om de använder underleverantörer (underbiträden) som kan få åtkomst till era data eller system. Dokumentera hur era informationssäkerhetskrav vidareförs till dessa parter, antingen genom leverantörens avtalsvillkor eller genom era egna direkta klausuler.

Detta är också beredskap för cybersäkerhetsreserven. Om en extern incidenthanteringsleverantör får tillträde till er miljö under ett nödläge måste ni känna till rättslig grund, åtkomstomfattning, regler för underlag, datahanteringsskyldigheter, samordningsväg till myndigheter och exitvillkor. DORA gör detta uttryckligt för finansiella entiteter. NIS2 gör det relevant för väsentliga och viktiga entiteter. ISO/IEC 27001:2022 gör det möjligt att granska.

GDPR: frågan om personuppgiftsincident inne i cyberkrisen

Inte varje cybersäkerhetsincident är en personuppgiftsincident, men varje allvarlig incident bör bedömas för den möjligheten.

GDPR gäller behandling inom ramen för ett etableringsställe i EU, och även för personuppgiftsansvariga eller biträden utanför EU som erbjuder varor eller tjänster till personer i EU eller övervakar deras beteende i EU. Den definierar personuppgifter, behandling, personuppgiftsansvarig, personuppgiftsbiträde och personuppgiftsincident. Dess principer omfattar riktighet, konfidentialitet och ansvarsskyldighet, vilket innebär att personuppgiftsansvariga måste kunna visa efterlevnad.

Under 03:17-incidenten måste Marias team fråga:

• Har personuppgifter lästs, röjts, ändrats, förlorats eller förstörts?
• Är InnovateCloud personuppgiftsansvarig, personuppgiftsbiträde eller båda för berörda data?
• Ingår särskilda kategorier av personuppgifter?
• Vilka kunder eller individer påverkas?
• Är loggarna tillräckliga för att bedöma omfattningen?
• Löper GDPR:s aviseringsskyldigheter parallellt med skyldigheter enligt NIS2 eller DORA?

Det är därför dataskyddssamordning hör hemma i incidenteskaleringen, inte i en sen juridisk granskning efter att system har byggts om och loggar har roterats.

SME-versionen Loggnings- och övervakningspolicy - SME Loggnings- och övervakningspolicy - SME anger:

Högprioriterade larm måste eskaleras till VD och integritetssamordnare inom 24 timmar

Den klausulen är enkel, men den löser ett verkligt felmönster. Dataskyddsombud behöver underlag medan det fortfarande är tillräckligt färskt för att avgöra om en personuppgiftsincident har inträffat och om individer är utsatta för risk.

Bygg ett 24-timmars underlagspaket för gränsöverskridande incidenter

En praktisk beredskapsövning bör simulera de första 24 timmarna av en gränsöverskridande incident. Målet är inte att överrapportera. Målet är att visa att organisationen kan sammanställa fakta, fatta försvarbara beslut och hålla kommunikationen konsekvent.

Scenario

Er MSSP detekterar misstänkt privilegierad åtkomst från en ovanlig region mot er produktionskundmiljö. Samma källinfrastruktur förekommer i larm som påverkar två kunder i två medlemsstater. En kund är en finansiell entitet. Den berörda miljön innehåller personuppgifter, men exfiltration är inte bekräftad.

Steg 1: Öppna incidentposten

Skapa incidentärendet med godkända klassificeringsfält. Inkludera tidpunkt för kännedom, detekteringskälla, påverkade tillgångar, påverkade tjänster, länder som potentiellt påverkas, misstänkt skadlig aktivitet, inledande allvarlighetsgrad och incidentledare.

Koppla detta till ISO/IEC 27002:2022-kontrollerna 5.24, 5.25 och 5.26 samt till ISO/IEC 27001:2022-kontrollerna A.5.24, A.5.25 och A.5.26 i bilaga A.

Steg 2: Aktivera beslutsflödet för myndighetskontakt

Använd den kontaktmatris för myndigheter som krävs enligt Zenith Blueprint steg 22. Identifiera vilka myndigheter som kan vara relevanta: nationell CSIRT, dataskyddsmyndighet, finansiell tillsynsmyndighet, brottsbekämpande myndighet och sektortillsynsmyndighet.

Dokumentera beslutet och motiveringen. Om en tidig varning enligt NIS2 inte görs, dokumentera varför. Om gränsöverskridande påverkan är möjlig, dokumentera underlaget som stödjer den slutsatsen.

Steg 3: Bevara underlag före större avhjälpande åtgärder

Enterprise-versionen av Policy för bevisinsamling och forensik Policy för bevisinsamling och forensik anger:

All insamlad bevisning ska identifieras unikt, märkas och lagras i ett säkert dokumentarkiv med:

SME-versionen Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME ger samma disciplin i enklare form:

”Varje objekt av digital bevisning måste loggas med:”

Från Evidence Collection and Forensics Policy - SME, avsnittet ”Styrningskrav”, klausul 5.2.1.

För scenarioövningen, samla exempelposter för underlag: SIEM-larmexport, loggar från identitetsleverantör, poster från privilegierade sessioner, ögonblicksbild från slutpunkt, brandväggsloggar, revisionsloggar från molnmiljö, noteringar om kundpåverkan och kommunikationsgodkännanden.

Steg 4: Aktivera leverantörsstöd

Kontrollera leverantörsregistret. Identifiera MSSP:n, molnleverantören och kritiska underleverantörer. Bekräfta klausuler för incidentstöd, eskaleringskontakter, bevarandetider för loggar, underlagsformat och skyldigheter att samarbeta med myndigheter.

Detta stödjer direkt DORA:s krav på IKT-tredjepartsrisk och NIS2:s förväntningar på säkerhet i leveranskedjan.

Steg 5: Ta fram tre kommunikationer

Ta fram tre kommunikationer från samma faktabas:

Steg 6: Avsluta med erfarenhetsåterföring

Uppdatera riskregistret, Statement of Applicability, leverantörsregistret och incidenthanteringsplanen. Om övningen visar saknade loggar, otydliga myndighetskontakter eller svaga leverantörsklausuler, skapa korrigerande åtgärder.

Zenith Blueprint, fasen Controls in Action, steg 23, instruerar organisationer att validera incidentförmågor på följande sätt:

Välj en nyligen inträffad händelse eller genomför en scenarioövning vid bord för att validera er plan. Fånga och logga alla beslut, roller och all kommunikation (5.26), och uppdatera planen med erfarenhetsåterföring (5.27). Bekräfta att rutiner finns på plats för att bevara forensisk bevisning (5.28), inklusive ögonblicksbilder av loggar, säkerhetskopior och säker isolering av påverkade system.

Det stycket är en övningsagenda som är förberedd för revision.

Loggning: skillnaden mellan samordning och spekulation

Samordning av gränsöverskridande incidenter misslyckas när alla har uppfattningar men ingen har tidsstämplar.

Zenith Blueprint, fasen Controls in Action, steg 19, uttrycker det tydligt:

Loggning är livsnerven i varje säker IT-miljö. Utan den förblir incidenter osynliga, ansvarsskyldighet bleknar och orsakssamband försvinner i tomma intet.

Den fortsätter:

I grunden handlar loggning om spårbarhet. När något går fel, oavsett om det är ett misslyckat inloggningsförsök, radering av kritiska filer eller ett obehörigt skript som körs på en server, ger loggar den forensiska tråd som hjälper er att reda ut vad som faktiskt hände.

För NIS2 stödjer loggar 72-timmarsincidentanmälan med inledande allvarlighetsgrad, påverkan och indikatorer på kompromettering. För DORA stödjer loggar klassificering av större IKT-relaterade incidenter, rotorsaksanalys, operativ påverkan och tredjepartsansvar. För GDPR stödjer loggar bedömningen av om personuppgifter har lästs eller röjts. I en Cyber Solidarity Act-kontext stödjer loggar gemensam lägesbild utan att incidenthanterare behöver förlita sig på spekulation.

Om svaret på någon fråga är ”osäkert” hör frågan hemma i riskbehandlingsplanen.

Verksamhetskontinuitet och säker krisdrift

Diskussionen om Cyber Solidarity Act fokuserar naturligt på incidenthantering, men resiliens innebär också att hålla kritiska tjänster säkra under störning.

NIS2 Article 21 kräver en allriskansats som omfattar incidenthantering, verksamhetskontinuitet, hantering av säkerhetskopiering, katastrofåterställning, krishantering, säkerhet i leveranskedjan, hantering av sårbarheter, effektivitetsbedömning, cyberhygien, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering, flerfaktorsautentisering, säker kommunikation och säkrad nödkommunikation där så är lämpligt.

DORA kräver på liknande sätt styrning, IKT-riskhantering, incidenthantering, resiliensprovning, hantering av tredjepartsrisk, kontinuitet och återställning. Mindre entiteter kan ha förenklade krav, men de behöver fortfarande dokumenterad IKT-riskhantering, övervakning, resilienta system, incidenthantering, identifiering av tredjepartsberoenden, säkerhetskopior, återställning, testning, lärande efter incident och utbildning.

Enterprise-versionen av Policy för verksamhetskontinuitet och katastrofåterställning Policy för verksamhetskontinuitet och katastrofåterställning utgår från ett enkelt krav:

Planer ska omfatta:

Bakom den frasen finns det kontinuitetsunderlag som revisorer förväntar sig: återställningsprioriteringar, Recovery Time Objective (RTO), Recovery Point Objective (RPO), scheman för säkerhetskopiering, återställningstester, krisroller, alternativa kommunikationskanaler, leverantörsberoenden och förbättringsåtgärder efter övning.

ISO/IEC 27002:2022-kontrollerna 5.29 och 5.30 är centrala här. Kontroll 5.29 behandlar informationssäkerhet under störning. Kontroll 5.30 behandlar IKT-beredskap för verksamhetskontinuitet. I Zenith Controls kopplas incidentplanering enligt 5.24 till säkerhet under störning och bredare kontinuitetsplanering. Detta är särskilt relevant när normala kanaler inte är tillgängliga, identitetssystem är degraderade eller kristeam måste samordna med myndigheter via säkrad nödkommunikation.

Korsvis efterlevnadskarta: NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019

En CISO behöver inte fem separata incidentprogram. De behöver en underlagsmodell som kan betraktas genom fem linser.

NIST CSF 2.0-metoden med Current and Target Profile är särskilt användbar för organisationer som ännu inte är mogna nog för en fullt integrerad GRC-plattform. Den uppmuntrar organisationer att avgränsa en profil, samla in input såsom policyer, verksamhetens riskprioriteringar, affärskonsekvensanalyser, krav, standarder, rutiner, skyddsåtgärder och roller, därefter analysera gap och skapa en prioriterad åtgärdsplan. Det ligger nära en praktisk beredskapssprint för Cyber Solidarity Act: aktuellt underlag, målkrav, gapplan, ägare, datum och revisionsspår.

COBIT 2019- och ISACA-liknande revisorer tenderar att fråga om styrningsmål är ägda, mätta och övervakade. De nöjer sig inte med ”SOC hanterar det”. De kommer att fråga hur ledningsorgan godkänner riskåtgärder, hur resultat rapporteras, hur tredjepartsrisk styrs, hur undantag accepteras och hur korrigerande åtgärder följs upp.

Hur revisorer testar samma incident

Samma 03:17-incident ger olika revisionsfrågor beroende på granskarens mandat.

En ISO/IEC 27001:2022-revisor börjar med ISMS. Revisorn frågar om incidentprocessen omfattas, om intressentkrav inkluderar NIS2, DORA, GDPR och avtal, om riskbedömningen beaktade gränsöverskridande scenarier och leverantörsscenarier, om kontroller i bilaga A valdes i Statement of Applicability och om operativa poster visar att processen följdes.

En NIS2-inriktad myndighet eller granskare fokuserar på ledningsansvar, riskhanteringsåtgärder enligt Article 21 och rapportering enligt Article 23. De kan fråga när organisationen fick kännedom, varför incidenten var eller inte var betydande, hur gränsöverskridande påverkan bedömdes, om kunder informerades och om korrigerande åtgärder vidtogs utan onödigt dröjsmål.

En DORA-tillsynsmyndighet eller internrevision frågar om incidenten påverkade kritiska eller viktiga funktioner, om IKT-tredjepartsleverantörer stödde responsen, om den finansiella entiteten behöll ansvaret, om informationsregistret var korrekt, om incidenten klassificerades korrekt och om erfarenhetsåterföring matades tillbaka till resiliensprovning och leverantörstillsyn.

En GDPR-revisor eller dataskyddsmyndighet frågar om organisationen hade tillräckligt underlag för att avgöra om personuppgifter hade komprometterats, om rollerna som personuppgiftsansvarig och personuppgiftsbiträde var tydliga, om registrerade var utsatta för risk, om kontroller för konfidentialitet och riktighet var lämpliga och om poster för ansvarsskyldighet upprätthölls.

En NIST CSF 2.0-granskare översätter händelsen till utfall inom Govern, Identify, Protect, Detect, Respond och Recover. De letar efter intressentförväntningar, rättsliga skyldigheter, riskaptit, leverantörsstyrning, loggning, övervakning, genomförande av respons, kommunikation och återställningsvalidering.

En COBIT 2019- eller ISACA-revisor fokuserar på styrning och ledningssystemets effektivitet: ägarskap, beslutsrättigheter, mätetal, riskacceptans, processprestanda, kontrollsäkring och ständig förbättring.

Här är Zenith Controls användbar som kompass för korsvis efterlevnad. Den byter inte namn på officiella kontroller och skapar inte ett parallellt kontrollramverk. Den visar hur ISO/IEC 27002:2022-kontroller såsom 5.5, 5.24 och 5.28 kopplas till operativa förmågor, relaterade kontroller och revisionsrelevant underlag.

Vad CISO:er bör göra nu för beredskap 2026

Om ni förbereder er för den operativa verklighet som EU:s cybersolidaritetsakt skapar, börja med underlag, inte slogans.

För det första, uppdatera ert ISMS-sammanhang och er intressentanalys. Identifiera om er organisation, era kunder eller era leverantörer omfattas av NIS2, DORA eller GDPR. Inkludera närvaro i medlemsstater, sektorklassificering, kritiska kunder, IKT-tjänsteberoenden och myndighetskontakter.

För det andra, genomför en gränsöverskridande scenarioövning vid bord. Använd ett scenario som omfattar en leverantör, fler än en medlemsstat, möjlig exponering av personuppgifter och en reglerad finansiell kund. Tidsbegränsa de första 24 timmarna.

För det tredje, granska leverantörsavtal. Bekräfta aviseringsskyldigheter, åtkomst till loggar, forensiskt stöd, samarbete med myndigheter, vidareförda skyldigheter till underleverantörer, dataplats, revisionsrätt, kontinuitetsstöd och rätt att säga upp avtalet.

För det fjärde, testa bevisinsamling. Exportera loggar, bevara ögonblicksbilder, märk bevisning, registrera beviskedja och validera åtkomst till lagringsplats. Om er policy säger att bevisning är unikt identifierad och säkert lagrad, visa det.

För det femte, samordna incidentkommunikation. Er tidiga varning enligt NIS2, DORA-eskalering, bedömning av personuppgiftsincident enligt GDPR och kundmeddelande ska inte motsäga varandra. De kan ha olika rättsliga syften, men de måste bygga på samma faktabas.

För det sjätte, gör styrelsen till en del av övningen. Både NIS2 och DORA höjer ledningsansvaret. ISO/IEC 27001:2022-klausulerna om ledarskap gör detta möjligt att granska. En styrelse som aldrig har sett en 24-timmarsfrist för cyberavisering är inte redo för en gränsöverskridande kris.

Nästa steg med Clarysec

Framtiden för EU:s cybersäkerhet bygger på samarbete och bevisat förtroende. Organisationer som behandlar NIS2 och DORA som isolerade checklistor får svårt under gränsöverskridande incidenter. Organisationer som bygger evidensbaserade operativa system enligt ISO/IEC 27001:2022 kan svara tillsynsmyndigheter, kunder, revisorer och krishanterare med tillförsikt.

Clarysec hjälper CISO:er, complianceansvariga, revisorer och verksamhetsägare att omvandla EU:s cyberreglering till operativt underlag med revisionsberedskap genom:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap för strukturerat införande av ISO/IEC 27001:2022 och revisionssekvensering.
• Zenith Controls: The Cross-Compliance Guide för mappning av kontroller för incident, myndighet, leverantör, underlag, loggning och kontinuitet över flera ramverk.
• Clarysecs policymallar, inklusive Incidenthanteringspolicy, Policy för bevisinsamling och forensik, Policy för leverantörssäkerhet och tredjepartssäkerhet, Policy för verksamhetskontinuitet och katastrofåterställning, samt SME-versioner där proportionalitet är viktig.

Den bästa tiden att förbereda sig för samordning av gränsöverskridande incidenter är före 03:17-larmet. Den näst bästa tiden är idag.

Börja med en beredskapsgranskning från Clarysec, ladda ned relevant policyverktygslåda eller begär en genomgång av hur Zenith Blueprint och Zenith Controls kan hjälpa ert ISMS att skapa det underlag som cyberresiliens 2026 kommer att kräva.