Klar til EU's cybersolidaritetsforordning med ISO 27001

03:17-hændelsen, der gør EU-samarbejde til dit revisionsproblem

Klokken 03:17 en tirsdag morgen sidder Maria, CISO hos InnovateCloud, og ser på en skærm fyldt med alarmer. Hendes virksomhed er en mellemstor europæisk SaaS-udbyder, der leverer til logistikkunder i Tyskland, Frankrig og Polen. Den første alarm ligner mistænkelig privilegeret adgang i en produktionstenant. Ti minutter senere rapporterer MSSP’en tilsvarende aktivitet, der påvirker to andre kunder. Klokken 04:00 ser SOC’et API-kald fra infrastruktur, der tidligere har været forbundet med forberedelse af ransomware.

InnovateCloud var ikke det oprindelige mål. En central infrastrukturudbyder ser ud til at ligge inden for hændelsens påvirkningsområde. Konsekvensen er imidlertid nu Marias problem.

Én berørt kunde er en tysk bank, der kræver svar efter DORA. En anden er en kritisk leverandør i energisektoren, som allerede er klassificeret efter nationale NIS2-regler. Miljøet kan indeholde personoplysninger, men eksfiltrering er endnu ikke bekræftet. Sikkerhedsteamet vil inddæmme truslen med det samme. Juridisk afdeling vil vide, om NIS2-fristen for tidlig varsling på 24 timer er begyndt. Den databeskyttelsesansvarlige spørger, om anmeldelse af brud på persondatasikkerheden efter GDPR kan blive relevant. Bestyrelsen vil vide, om driftsafbrydelsen kan brede sig på tværs af medlemsstater.

I 2026 er dette ikke længere blot en intern krise.

EU’s cybersolidaritetsforordning ændrer den operationelle virkelighed for store og grænseoverskridende cyberhændelser. Den indfører mekanismer for detektion, beredskab og respons på EU-niveau, herunder det europæiske cybersikkerhedsvarslingssystem, cybersikkerhedskrisemekanismen og EU’s cybersikkerhedsreserve. Selv hvis en organisation aldrig direkte anmoder om bistand fra reserven, kan dens revisionsbevis, myndighedskontakter, leverandørkontrakter, hændelsestidslinjer og kundekommunikation blive en del af en bredere europæisk responskæde.

Gabet viser sig hurtigt. Mange organisationer har værktøjer, tickets og politikker, men ikke revisionsbevis, der kan modstå regulatorisk kontrol. De kan sige: “vi kontaktede tilsynsmyndigheden”, men kan ikke dokumentere, hvem der var bemyndiget, hvilken tærskel der udløste kontakten, hvad der blev kommunikeret, om logfiler blev bevaret, om en leverandør var kontraktligt forpligtet til at bistå, eller om en slutrapport kan rekonstrueres ud fra samtidige beslutninger.

Svaret er ikke endnu en isoleret “mappe til cybersolidaritetsforordningen”. Svaret er et ISO/IEC 27001:2022-ledelsessystem for informationssikkerhed, der producerer revisionsbevis én gang og genbruger det på tværs af forventningerne i NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019.

Det revisionsbevis opstår før hændelsen.

Hvorfor EU’s cybersolidaritetsforordning hæver kravene til revisionsbevis

Cybersolidaritetsforordningen er udformet til cyberdetektion, beredskab og kriserespons på EU-niveau. Den praktiske konsekvens for CISO’er, revisorer og compliance-ansvarlige er klar: koordinering af større hændelser kræver revisionsbevis, der er hurtigere, mere konsistent, bedre struktureret og lettere at dele med betroede interessenter.

Når grænseoverskridende påvirkning er mulig, kan en organisation skulle koordinere med nationale CSIRT’er, kompetente myndigheder, sektortilsyn, databeskyttelsesmyndigheder, finansielle tilsynsmyndigheder, retshåndhævende myndigheder, kunder, databehandlere, leverandører og eksterne hændelsesresponsudbydere. EU’s cybersikkerhedsreserve tilføjer endnu en dimension, fordi forhåndsgodkendte private udbydere kan understøtte beredskab, respons og genopretning. Det gør leverandørstyring, retsgrundlag, datahåndtering og bevarelse af bevismateriale endnu vigtigere.

Private enheder står centralt i denne virkelighed. Cloududbydere, datacentre, managed service providers, managed security service providers, operatører af digital infrastruktur, fintechs og SaaS-platforme ligger ofte inde med den telemetri, de logfiler, kundekonsekvensdata og tekniske fakta, som myndighederne behøver for at forstå en større hændelse.

NIS2 peger allerede i denne retning. Direktivet gælder for mange mellemstore og store enheder i sektorerne i bilag I og bilag II, som leverer tjenester eller udfører aktiviteter i EU. Det omfatter også visse enheder uanset størrelse, herunder tillidstjenesteudbydere, DNS-tjenesteudbydere, registre for topdomæner og tjenesteudbydere inden for domænenavnsregistrering. Bilag I omfatter digital infrastruktur såsom cloud computing-tjenester, datacentertjenester, content delivery networks, DNS-udbydere, tillidstjenesteudbydere og TLD-registre. Det omfatter også IKT-tjenestestyring B2B, herunder managed service providers og managed security service providers. Bilag II omfatter digitale udbydere såsom onlinemarkedspladser, onlinesøgemaskiner og platforme for sociale netværkstjenester.

DORA tilføjer et andet lag for den finansielle sektor. Siden 17. januar 2025 har den været gældende for en bred kreds af finansielle enheder, herunder kreditinstitutter, betalingsinstitutter, e-pengeinstitutter, investeringsselskaber, udbydere af kryptoaktivtjenester, handelspladser, forsikrings- og genforsikringsselskaber, kreditvurderingsbureauer, udbydere af crowdfunding-tjenester og andre. Den skaber også væsentlige forventninger til IKT-tredjepartsudbydere, fordi finansielle enheder fortsat er ansvarlige for outsourcede IKT-tjenester.

En fintech-hændelse i 2026 kan derfor blive koordineret gennem DORA-tilsynskanaler, mens den SaaS-udbyder eller MSSP, der understøtter fintech-virksomheden, kan være omfattet af NIS2. Den samme tekniske hændelse kan skabe forskellige rapporteringsforpligtelser, forventninger til revisionsbevis og kontraktlige forpligtelser for forskellige aktører.

ISO/IEC 27001:2022 giver organisationer den driftsmodel, der kan håndtere denne kompleksitet. Klausul 4.1 til 4.4 kræver, at organisationen definerer ISMS’et i sin forretningsmæssige kontekst, identificerer interessenter og deres retlige, regulatoriske og kontraktlige krav, definerer grænser og afhængigheder og etablerer ledelsessystemet. Klausul 5.1 til 5.3 gør ledelsen ansvarlig for politik, ressourcer, integration og rolletildeling. Klausul 6.1.1 til 6.1.3 kræver gentagelig risikovurdering, risikobehandling og en anvendelighedserklæring. Klausul 8.1 kræver operationel styring, herunder styring af eksternt leverede processer, produkter og tjenester.

Dette er kernen i parathed til cybersolidaritetsforordningen: at dokumentere, at kriserespons er styret, testet og reviderbar, ikke improviseret.

Clarysecs model for revisionsbevis: én hændelse, mange forpligtelser

En grænseoverskridende hændelse venter ikke på, at juridiske teams klassificerer den. Revisionsbevis skal indsamles fra den første alarm og derefter kanaliseres ind i de rette rapporterings- og koordineringsspor.

Clarysecs tilgang forbinder tre aktiver:

1. Zenith Blueprint: en revisors 30-trins køreplan Zenith Blueprint, som omsætter ISO/IEC 27001:2022-implementering til et sekventeret, revisionsklart forløb.
2. Zenith Controls: guiden til kortlægning på tværs Zenith Controls, som kortlægger ISO/IEC 27002:2022-kontroller til relaterede kontroller, attributter, operationelle kapaciteter, sikkerhedsdomæner og forventninger til revisionsbevis på tværs af rammeværker.
3. Clarysec-politikskabeloner til hændelseshåndtering, indsamling af bevismateriale, leverandørsikkerhed, logning, overvågning og forretningskontinuitet, tilpasset enterprise- og SMV-miljøer.

I Zenith Blueprint, fasen Kontroller i praksis, behandler trin 22 ISO/IEC 27002:2022-kontrol 5.5, kontakt med myndigheder. Den fastslår:

Kontrol 5.5 sikrer, at en organisation er forberedt på at interagere med eksterne myndigheder, når det er nødvendigt, ikke reaktivt eller i panik, men gennem foruddefinerede, strukturerede og vel- forståede kanaler.

Samme afsnit stiller det spørgsmål, enhver CISO bør kunne besvare før krisen:

hvis din organisation blev mål for et cyberangreb, involveret i et brud på persondatasikkerheden eller genstand for en undersøgelse, hvem ville så tage kontakten til myndighederne? Hvordan ville de vide, hvad de skulle sige? Under hvilke betingelser ville en sådan kontakt blive iværksat?

Det er ikke administrativt papirarbejde. I et miljø præget af cybersolidaritetsforordningen er det forskellen mellem en rolig tidlig varsling og modstridende budskaber på tværs af jurisdiktioner.

Zenith Controls behandler ISO/IEC 27002:2022-kontrol 5.5, kontakt med myndigheder, som forebyggende og korrigerende, knyttet til fortrolighed, integritet og tilgængelighed og tilpasset begreberne Identify, Protect, Respond og Recover. Den forbinder 5.5 med planlægning og forberedelse af hændelsesstyring, rapportering af hændelser, trusselsintelligens, interessegrupper og respons på hændelser.

Den samme guide behandler ISO/IEC 27002:2022-kontrol 5.24, planlægning og forberedelse af styring af informationssikkerhedshændelser, som en korrigerende kontrol knyttet til Respond og Recover. Dens sammenhæng med hændelsesvurdering, hændelseshåndtering, læringspunkter, logning, overvågning, sikkerhed under driftsforstyrrelser og kontinuitet viser, hvad revisorer ofte tester: om planen forbinder detektion, klassificering, eskalering, revisionsbevis, genopretning og læring.

For håndtering af bevismateriale er ISO/IEC 27002:2022-kontrol 5.28, indsamling af bevismateriale, særligt vigtig. Zenith Controls forbinder den med hændelseshåndtering, logning, overvågning og rapportering af hændelser. Ved en alvorlig grænseoverskridende hændelse er det her, den tekniske undersøgelse bliver forsvarlig.

Kortlægning af parathed til cybersolidaritetsforordningen til ISO 27001-revisionsbevis

EU’s cybersolidaritetsforordning skaber et miljø for beredskab og koordinering. ISO/IEC 27001:2022 leverer motoren til revisionsbevis. NIS2, DORA og GDPR definerer mange konkrete forventninger til rapportering, styring og beskyttelse.

Bemærk, hvad der ikke er der: en separat compliance-silo. Det samme revisionsbevis, der understøtter ISO/IEC 27001:2022-certificering, kan understøtte ledelsesansvar efter NIS2, DORA-styring af IKT-risiko, GDPR-ansvarlighed for sikkerhed, kommunikationsresultater i NIST CSF og COBIT 2019-forventninger til assurance.

NIS2: rapporteringsfristen starter, når konstatering sker

NIS2 er centralt for parathed i 2026, fordi det definerer en trinvis arbejdsgang for hændelsesrapportering.

Article 23 kræver, at væsentlige og vigtige enheder uden unødigt ophold underretter deres CSIRT eller kompetente myndighed om væsentlige hændelser, der påvirker levering af tjenester. Den tidlige varsling skal indsendes uden unødigt ophold og senest 24 timer efter, at enheden er blevet bekendt med den væsentlige hændelse. Den skal, hvor det er relevant, angive, om der er mistanke om ondsindede eller ulovlige handlinger, og om grænseoverskridende påvirkning er mulig.

En hændelsesunderretning følger uden unødigt ophold og senest 72 timer efter konstatering, opdaterer den tidlige varsling og giver en indledende vurdering af alvorlighed, påvirkning og tilgængelige kompromitteringsindikatorer. En slutrapport skal indsendes senest én måned efter hændelsesunderretningen med alvorlighed, påvirkning, sandsynlig trusselstype eller rodårsag, risikobegrænsende foranstaltninger og grænseoverskridende påvirkning.

Derfor kan hændelseshåndtering ikke starte med et tomt dokument.

Enterprise-udgaven af Politik for hændelseshåndtering Politik for hændelseshåndtering fastslår:

NIS2 Article 23 (underretning inden for 24 timer efter konstatering af hændelsen)

SMV-udgaven Politik for hændelseshåndtering - SMV Politik for hændelseshåndtering - SMV omsætter den samme tidslogik til praktisk styring:

“Tidsfrister for respons, herunder datagendannelse og underretningsforpligtelser, skal dokumenteres og være afstemt med retlige krav, såsom GDPR-kravet om anmeldelse af brud på persondatasikkerheden inden for 72 timer.”

Fra Politik for hændelseshåndtering - SMV, afsnittet “Styringskrav”, klausul 5.3.2.

Den tvinger også vurderingen på tværs af regelsæt ind i hændelsesprocessen:

“Når kundedata er involveret, skal direktøren vurdere retlige underretningsforpligtelser baseret på anvendeligheden af GDPR, NIS2 eller DORA.”

Fra Politik for hændelseshåndtering - SMV, afsnittet “Risikobehandling og undtagelser”, klausul 7.4.1.

I et scenarie omfattet af cybersolidaritetsforordningen bliver “grænseoverskridende påvirkning er mulig” operationelt vigtigt. Den tidlige varsling har måske ikke alle fakta, men organisationen skal kunne dokumentere, hvorfor den mistænkte eller ikke mistænkte grænseoverskridende påvirkning på baggrund af det tilgængelige revisionsbevis.

Hændelsesregistreringen bør indfange:

• Hvornår organisationen blev bekendt med hændelsen.
• Hvem der erklærede hændelsen som en potentiel hændelse.
• Hvilke tjenester, lande, kunder eller sektorer der potentielt var berørt.
• Om der var mistanke om ondsindet eller ulovlig aktivitet.
• Hvilke kompromitteringsindikatorer der var tilgængelige.
• Hvilken kontaktvej til myndigheder der blev anvendt.
• Om kundekommunikation var nødvendig.
• Hvilket revisionsbevis der blev bevaret før væsentlig afhjælpning.

Det bedste tidspunkt at designe disse felter er før 03:17.

DORA: når kunden er reguleret, men leverandøren har logfilerne

DORA ændrer leverandørsamtalen. Finansielle enheder skal styre IKT-tredjepartsrisiko som en del af deres ramme for IKT-risikostyring. Outsourcing af IKT-tjenester flytter ikke det regulatoriske ansvar væk fra den finansielle enhed.

DORA kræver strategier for IKT-tredjepartsrisiko, registre over IKT-tjenestekontrakter, due diligence, planlægning af revision og inspektion, opsigelsesrettigheder og testede exitstrategier for kritiske eller vigtige IKT-tjenester. Article 30 kræver kontraktlig klarhed, herunder servicebeskrivelser, lokationer, datahåndtering, fortrolighed, integritet, tilgængelighed, serviceniveauer, bistand under IKT-hændelser, samarbejde med myndigheder og opsigelsesrettigheder. For kritiske eller vigtige funktioner gælder strengere vilkår.

Vend tilbage til Marias hændelse. Den tyske bank er reguleret efter DORA. InnovateCloud leverer SaaS-tjenester. MSSP’en detekterer mistænkelig aktivitet. Cloudinfrastrukturudbyderen har nogle af de centrale revisionslogfiler. En underleverandør driver en del af telemetripipelinen. Banken er fortsat ansvarlig, men kan ikke klassificere og rapportere korrekt uden leverandørens revisionsbevis.

Clarysec håndterer dette gennem leverandørklassificering og kontraktligt revisionsbevis. Enterprise-udgaven af Politik for tredjeparts- og leverandørsikkerhed Politik for tredjeparts- og leverandørsikkerhed kræver:

Kontrakter med leverandører skal omfatte:

SMV-udgaven Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV bruger den samme efterlevelseslogik i en lettere driftsmodel:

Kontrakter skal indeholde obligatoriske klausuler, der dækker:

Værdien ligger i skemaet bag disse ord: underretningspligter ved hændelser, adgang til logfiler, revisionsrettigheder, fortrolighed, datalokation, underleverandørkontroller, samarbejde med myndigheder, genopretningsstøtte og exitforpligtelser.

Zenith Blueprint, fasen Kontroller i praksis, trin 23, giver implementeringsvejen:

Udarbejd en fuldstændig liste over nuværende leverandører og tjenesteudbydere (5.19), og klassificér dem baseret på adgang til systemer, data eller operationel styring. For hver klassificeret leverandør skal det verificeres, at sikkerheds- forventninger er klart indarbejdet i kontrakter (5.20), herunder fortrolighed, adgang, hændelsesrapportering og efterlevelsesforpligtelser.

Den fortsætter med downstream-risiko:

For hver kritisk leverandør skal det identificeres, om de anvender underleverandører (underdatabehandlere), som kan få adgang til dine data eller systemer. Dokumentér, hvordan dine informationssikkerhedskrav videreføres til disse parter, enten gennem leverandørens kontraktvilkår eller dine egne direkte klausuler.

Dette er også parathed til cybersikkerhedsreserven. Hvis en ekstern responsudbyder får adgang til dit miljø under en nødsituation, skal du kende retsgrundlaget, adgangsomfanget, reglerne for bevismateriale, datahåndteringsforpligtelserne, koordineringsvejen til myndigheder og exitbetingelserne. DORA gør dette eksplicit for finansielle enheder. NIS2 gør det relevant for væsentlige og vigtige enheder. ISO/IEC 27001:2022 gør det reviderbart.

GDPR: spørgsmålet om brud inde i cyberkrisen

Ikke enhver cybersikkerhedshændelse er et brud på persondatasikkerheden, men enhver alvorlig hændelse bør vurderes for den mulighed.

GDPR gælder for behandling i forbindelse med en etablering i EU og også for dataansvarlige eller databehandlere uden for EU, der tilbyder varer eller tjenester til personer i EU eller overvåger deres adfærd i EU. Den definerer personoplysninger, behandling, dataansvarlig, databehandler og brud på persondatasikkerheden. Dens principper omfatter integritet, fortrolighed og ansvarlighed, hvilket betyder, at dataansvarlige skal kunne dokumentere efterlevelse.

Under 03:17-hændelsen skal Marias team spørge:

• Blev personoplysninger tilgået, videregivet, ændret, mistet eller destrueret?
• Er InnovateCloud dataansvarlig, databehandler eller begge dele for de berørte data?
• Er særlige kategorier af personoplysninger involveret?
• Hvilke kunder eller personer er berørt?
• Er logfilerne tilstrækkelige til at vurdere omfanget?
• Løber underretningsforpligtelser efter GDPR parallelt med forpligtelser efter NIS2 eller DORA?

Derfor hører databeskyttelseskoordinering hjemme i hændelseseskaleringen, ikke i en sen juridisk gennemgang, efter at systemer er genopbygget, og logfiler er roteret.

SMV-udgaven af Lognings- og overvågningspolitik - SMV Lognings- og overvågningspolitik - SMV fastslår:

Højprioritetsalarmer skal eskaleres til direktøren og koordinator for databeskyttelse inden for 24 timer

Den klausul er enkel, men den løser et reelt fejlmønster. Databeskyttelsesansvarlige har brug for revisionsbevis, mens det stadig er tilstrækkeligt friskt til at fastslå, om der er sket et brud på persondatasikkerheden, og om personer er i risiko.

Opbyg en 24-timers bevispakke til grænseoverskridende hændelser

En praktisk parathedsøvelse bør simulere de første 24 timer af en grænseoverskridende hændelse. Målet er ikke at overrapportere. Målet er at dokumentere, at organisationen kan samle fakta, træffe forsvarlige beslutninger og holde kommunikationen konsistent.

Scenarie

Din MSSP detekterer mistænkelig privilegeret adgang fra en usædvanlig region mod din produktionstenant. Den samme kildeinfrastruktur optræder i alarmer, der påvirker to kunder i to medlemsstater. Én kunde er en finansiel enhed. Det berørte miljø indeholder personoplysninger, men eksfiltrering er ikke bekræftet.

Trin 1: Opret hændelsesregistreringen

Opret hændelsesticketen med godkendte klassificeringsfelter. Medtag tidspunkt for konstatering, detektionskilde, påvirkede aktiver, påvirkede tjenester, potentielt berørte lande, mistænkt ondsindet aktivitet, indledende alvorlighed og hændelsesleder.

Knyt dette til ISO/IEC 27002:2022-kontrollerne 5.24, 5.25 og 5.26 og til ISO/IEC 27001:2022 bilag A-kontrollerne A.5.24, A.5.25 og A.5.26.

Trin 2: Udløs beslutningsflowet for myndighedskontakt

Brug den kontaktmatrice for myndigheder, som kræves i Zenith Blueprint trin 22. Identificér, hvilke myndigheder der kan være relevante: national CSIRT, databeskyttelsesmyndighed, finansielt tilsyn, retshåndhævende myndighed og sektortilsyn.

Registrér beslutningen og begrundelsen. Hvis der ikke indsendes en tidlig NIS2-varsling, skal årsagen dokumenteres. Hvis grænseoverskridende påvirkning er mulig, skal det revisionsbevis, der understøtter konklusionen, registreres.

Trin 3: Bevar bevismateriale før væsentlig afhjælpning

Enterprise-udgaven af Politik for indsamling af bevismateriale og digital efterforskning Politik for indsamling af bevismateriale og digital efterforskning fastslår:

Alt indsamlet bevismateriale skal være entydigt identificeret, mærket og opbevaret i et sikkert repository med:

SMV-udgaven Politik for indsamling af bevismateriale og digital efterforskning - SMV Politik for indsamling af bevismateriale og digital efterforskning - SMV giver samme disciplin i enklere form:

“Hvert element af digitale beviser skal logges med:”

Fra Politik for indsamling af bevismateriale og digital efterforskning - SMV, afsnittet “Styringskrav”, klausul 5.2.1.

Til tabletop-øvelsen skal der indsamles eksempler på bevisposter: SIEM-alarmeksport, logfiler fra identitetsudbyder, registreringer af privilegerede sessioner, endpoint-snapshot, firewalllogfiler, cloudrevisionslogfiler, noter om kundepåvirkning og kommunikationsgodkendelser.

Trin 4: Aktivér leverandørbistand

Kontrollér leverandørregisteret. Identificér MSSP’en, cloududbyderen og kritiske underleverandører. Bekræft klausuler om hændelsesstøtte, eskalationskontakter, opbevaringsperioder for logfiler, format for bevismateriale og forpligtelser til myndighedssamarbejde.

Dette understøtter direkte DORA-krav til IKT-tredjepartsrisiko og NIS2-forventninger til sikkerhed i forsyningskæden.

Trin 5: Udarbejd tre kommunikationer

Udarbejd tre kommunikationer ud fra samme faktagrundlag:

Trin 6: Afslut med læringspunkter

Opdatér risikoregisteret, anvendelighedserklæringen, leverandørregisteret og hændelseshåndteringsplanen. Hvis øvelsen afslører manglende logfiler, uklare myndighedskontakter eller svage leverandørklausuler, skal der oprettes korrigerende handlinger.

Zenith Blueprint, fasen Kontroller i praksis, trin 23, instruerer organisationer i at validere hændelseskapaciteter på denne måde:

Vælg en nylig hændelse, eller gennemfør en tabletop-øvelse for at validere din plan. Indfang og log alle beslutninger, roller og kommunikationer (5.26), og opdatér planen med læringspunkter (5.27). Bekræft, at procedurer er på plads til at bevare forensisk bevismateriale (5.28), herunder logsnapshots, sikkerhedskopier, og sikker isolering af påvirkede systemer.

Det afsnit er en revisionsklar øvelsesagenda.

Logning: forskellen mellem koordinering og spekulation

Koordinering af grænseoverskridende hændelser fejler, når alle har holdninger, men ingen har tidsstempler.

Zenith Blueprint, fasen Kontroller i praksis, trin 19, formulerer det klart:

Logning er livsnerven i ethvert sikkert IT-miljø. Uden den forbliver hændelser usynlige, ansvarlighed forsvinder, og årsag-virkning-sammenhænge opløses.

Den fortsætter:

I sin kerne handler logning om sporbarhed. Når noget går galt, uanset om det er et mislykket loginforsøg, sletning af kritiske filer eller et uautoriseret script, der kører på en server, giver logfiler den forensiske tråd, der hjælper dig med at udrede, hvad der faktisk skete.

For NIS2 understøtter logfiler 72-timers hændelsesunderretningen med indledende alvorlighed, påvirkning og kompromitteringsindikatorer. For DORA understøtter logfiler klassificering af større IKT-relaterede hændelser, rodårsagsanalyse, operationel påvirkning og tredjeparts ansvarlighed. For GDPR understøtter logfiler vurderingen af, om personoplysninger blev tilgået eller videregivet. I en cybersolidaritetsforordningskontekst understøtter logfiler fælles situationsforståelse uden at tvinge respondere til at basere sig på spekulation.

Hvis svaret på et spørgsmål er “ikke sikker”, hører forholdet hjemme i risikobehandlingsplanen.

Forretningskontinuitet og sikre kriseoperationer

Samtalen om cybersolidaritetsforordningen fokuserer naturligt på hændelseshåndtering, men robusthed betyder også at holde kritiske tjenester sikre under driftsforstyrrelser.

NIS2 Article 21 kræver en all-hazards-tilgang, der dækker håndtering af hændelser, forretningskontinuitet, backupstyring, katastrofeberedskab, krisestyring, sikkerhed i forsyningskæden, sårbarhedshåndtering, effektivitetsvurdering, cyberhygiejne, kryptografi, HR-sikkerhed, adgangsstyring, politik for styring af aktiver, multifaktorgodkendelse, sikker kommunikation og sikret nødkommunikation, hvor det er relevant.

DORA kræver tilsvarende styring, IKT-risikostyring, hændelsesstyring, robusthedstest, tredjepartsrisikostyring, kontinuitet og genopretning. Mindre enheder kan have forenklede krav, men de har stadig behov for dokumenteret IKT-risikostyring, overvågning, robuste systemer, håndtering af hændelser, identifikation af tredjepartsafhængigheder, backups, gendannelse, test, læring efter hændelser og træning.

Enterprise-udgaven af Politik for forretningskontinuitet og politik for genopretning efter alvorlige hændelser Politik for forretningskontinuitet og politik for genopretning efter alvorlige hændelser tager udgangspunkt i et enkelt krav:

Planer skal dække:

Bag den formulering ligger det kontinuitetsrevisionsbevis, som revisorer forventer: genopretningsprioriteter, Recovery Time Objectives, Recovery Point Objectives, backupplaner, gendannelsestest, kriseroller, alternative kommunikationskanaler, leverandørafhængigheder og forbedringstiltag efter øvelser.

ISO/IEC 27002:2022-kontrollerne 5.29 og 5.30 er centrale her. Kontrol 5.29 omhandler informationssikkerhed under driftsforstyrrelser. Kontrol 5.30 omhandler IKT-parathed til forretningskontinuitet. I Zenith Controls er hændelsesplanlægning under 5.24 knyttet til sikkerhed under driftsforstyrrelser og bredere kontinuitetsplanlægning. Dette er især relevant, når normale kanaler ikke er tilgængelige, identitetssystemer er degraderede, eller kriseteams skal koordinere med myndigheder via sikret nødkommunikation.

Kort over sammenhænge: NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019

En CISO har ikke brug for fem separate hændelsesprogrammer. Vedkommende har brug for én model for revisionsbevis, der kan ses gennem fem linser.

NIST CSF 2.0-metoden med aktuel profil og målprofil er særligt nyttig for organisationer, der endnu ikke er modne nok til en fuldt integreret GRC-platform. Den tilskynder organisationer til at afgrænse en profil, indsamle input såsom politikker, organisationens risikoprioriteter, forretningskonsekvensanalyser, krav, standarder, procedurer, sikkerhedsforanstaltninger og roller, derefter analysere mangler og udarbejde en prioriteret handlingsplan. Det ligger tæt på et praktisk sprint for parathed til cybersolidaritetsforordningen: aktuelt revisionsbevis, målsatte forpligtelser, plan for mangler, ejere, datoer og revisionsspor.

COBIT 2019- og ISACA-revisorer vil typisk spørge, om styringsmål er ejet, målt og overvåget. De vil ikke stille sig tilfredse med “SOC håndterer det”. De vil spørge, hvordan ledelsesorganer godkender risikotiltag, hvordan performance rapporteres, hvordan tredjepartsrisiko styres, hvordan undtagelser accepteres, og hvordan korrigerende handlinger spores.

Hvordan revisorer vil teste den samme hændelse

Den samme 03:17-hændelse giver forskellige revisionsspørgsmål afhængigt af vurderingspartens mandat.

En ISO/IEC 27001:2022-revisor vil starte med ISMS’et. Revisoren vil spørge, om hændelsesprocessen er omfattet af omfanget, om interessentkrav omfatter NIS2, DORA, GDPR og kontrakter, om risikovurderingen har behandlet grænseoverskridende scenarier og leverandørscenarier, om bilag A-kontroller er valgt i anvendelighedserklæringen, og om driftsregistreringer dokumenterer, at processen blev fulgt.

En NIS2-fokuseret myndighed eller vurderingspart vil fokusere på ledelsesansvar, Article 21-risikostyringsforanstaltninger og Article 23-rapportering. De kan spørge, hvornår organisationen blev bekendt med hændelsen, hvorfor hændelsen var eller ikke var væsentlig, hvordan grænseoverskridende påvirkning blev vurderet, om kunder blev informeret, og om korrigerende foranstaltninger blev truffet uden unødigt ophold.

En DORA-tilsynsmyndighed eller intern revision vil spørge, om hændelsen påvirkede kritiske eller vigtige funktioner, om IKT-tredjepartsudbydere understøttede responsen, om den finansielle enhed bevarede ansvaret, om informationsregisteret var korrekt, om hændelsen blev klassificeret korrekt, og om læringspunkter blev ført tilbage til robusthedstest og leverandørtilsyn.

En GDPR-revisor eller databeskyttelsesmyndighed vil spørge, om organisationen havde tilstrækkeligt revisionsbevis til at afgøre, om personoplysninger var kompromitteret, om rollerne som dataansvarlig og databehandler var klare, om registrerede var i risiko, om kontroller for fortrolighed og integritet var passende, og om registreringer for ansvarlighed blev opretholdt.

En NIST CSF 2.0-vurderingspart vil omsætte hændelsen til resultater inden for Govern, Identify, Protect, Detect, Respond og Recover. De vil lede efter interessentforventninger, retlige forpligtelser, risikovillighed, leverandørstyring, logning, overvågning, udførelse af respons, kommunikation og validering af genopretning.

En COBIT 2019- eller ISACA-revisor vil fokusere på effektiviteten af styrings- og ledelsessystemet: ejerskab, beslutningsrettigheder, metrikker, risikoaccept, procesperformance, assurance og løbende forbedring.

Det er her, Zenith Controls er nyttig som kompas for kortlægning på tværs. Den omdøber ikke officielle kontroller og opretter ikke et parallelt kontrolrammeværk. Den viser, hvordan ISO/IEC 27002:2022-kontroller såsom 5.5, 5.24 og 5.28 hænger sammen med operationelle kapaciteter, relaterede kontroller og revisionsrelevant revisionsbevis.

Hvad CISO’er bør gøre nu for parathed i 2026

Hvis du forbereder dig på den operationelle virkelighed under EU’s cybersolidaritetsforordning, skal du starte med revisionsbevis, ikke slogans.

For det første skal ISMS-konteksten og interessentanalysen opdateres. Identificér, om din organisation, dine kunder eller dine leverandører er omfattet af NIS2, DORA eller GDPR. Medtag aftryk på tværs af medlemsstater, sektorklassificering, kritiske kunder, IKT-serviceafhængigheder og myndighedskontakter.

For det andet skal der gennemføres en grænseoverskridende tabletop-øvelse. Brug et scenarie, der omfatter en leverandør, mere end én medlemsstat, mulig eksponering af personoplysninger og en reguleret finansiel kunde. Afgræns de første 24 timer tidsmæssigt.

For det tredje skal leverandørkontrakter gennemgås. Bekræft underretningspligter, adgang til logfiler, forensisk support, myndighedssamarbejde, krav om videreførelse til underleverandører, datalokation, revisionsrettigheder, kontinuitetsstøtte og opsigelsesrettigheder.

For det fjerde skal indsamling af bevismateriale testes. Eksportér logfiler, bevar snapshots, mærk bevismateriale, registrér chain of custody og validér adgang til repository. Hvis din politik siger, at bevismateriale identificeres entydigt og opbevares sikkert, skal det dokumenteres.

For det femte skal hændelseskommunikation afstemmes. Din tidlige NIS2-varsling, DORA-eskalering, GDPR-vurdering af brud og kundemeddelelse må ikke modsige hinanden. De kan have forskellige juridiske formål, men de skal bygge på samme faktagrundlag.

For det sjette skal bestyrelsen være en del af øvelsen. NIS2 og DORA løfter begge ledelsesansvar. ISO/IEC 27001:2022-ledelsesklausulerne gør dette reviderbart. En bestyrelse, der aldrig har set en 24-timers cyberunderretningsfrist, er ikke klar til en grænseoverskridende krise.

Næste skridt med Clarysec

Fremtiden for EU’s cybersikkerhed er samarbejde og dokumenteret tillid. Organisationer, der behandler NIS2 og DORA som isolerede tjeklister, vil få vanskeligt ved grænseoverskridende hændelser. Organisationer, der bygger revisionsbevisbaserede ISO/IEC 27001:2022-driftsmodeller, vil kunne svare tilsynsmyndigheder, kunder, revisorer og kriserespondere med sikkerhed.

Clarysec hjælper CISO’er, compliance-ansvarlige, revisorer og virksomhedsejere med at omsætte EU’s cyberregulering til revisionsklart operationelt revisionsbevis gennem:

• Zenith Blueprint: en revisors 30-trins køreplan til struktureret ISO/IEC 27001:2022-implementering og revisionssekvensering.
• Zenith Controls: guiden til kortlægning på tværs til kortlægning af hændelses-, myndigheds-, leverandør-, bevis-, lognings- og kontinuitetskontroller på tværs af rammeværker.
• Clarysec-politikskabeloner, herunder Politik for hændelseshåndtering, Politik for indsamling af bevismateriale og digital efterforskning, Politik for tredjeparts- og leverandørsikkerhed, Politik for forretningskontinuitet og politik for genopretning efter alvorlige hændelser, samt SMV-versioner, hvor proportionalitet er afgørende.

Det bedste tidspunkt at forberede koordinering af grænseoverskridende hændelser på er før alarmen klokken 03:17. Det næstbedste tidspunkt er i dag.

Start med en Clarysec-parathedsgennemgang, download det relevante politikværktøjssæt, eller anmod om en gennemgang af, hvordan Zenith Blueprint og Zenith Controls kan hjælpe dit ISMS med at producere det revisionsbevis, som cyberrobusthed i 2026 vil kræve.