Løbende overvågning af efterlevelse for NIS2 og DORA

Spørgsmålet fredag eftermiddag, som enhver CISO nu skal kunne besvare

Kl. 16.40 en fredag modtager CISO’en i en cloudbaseret betalingsplatform tre beskeder inden for ti minutter.

Den første er fra CFO’en: “Vores bankpartner ønsker opdateret bevismateriale for, at vi lever op til DORA-forventningerne til IKT-tredjepartsrisiko og hændelsesrapportering.”

Den anden er fra virksomhedens juridiske chef: “Vores administrerede sikkerhedstjeneste kan bringe os inden for omfanget af den nationale implementering af NIS2. Kan vi dokumentere ledelsestilsyn og kontroleffektivitet?”

Den tredje er fra udviklingschefen: “Vi har patchet den kritiske sårbarhed, men backloggen viser 38 forfaldne mellemstore konstateringer. Skal vi eskalere?”

Det er her, årlig compliance bryder sammen.

En politik-PDF, et risikoregister, der sidst blev opdateret før den forrige revision, og en mappe med skærmbilleder er ikke tilstrækkeligt for NIS2 og DORA. Disse regelsæt forventer levende governance, ledelsestilsyn, hændelsesprocesser, leverandørsynlighed, robusthedstest, korrigerende handlinger og dokumenterbar kontroleffektivitet.

For mange CISO’er er presset ikke teoretisk. Gennemførelsen af NIS2 i EU’s medlemsstater har flyttet cybersikkerhed fra et teknisk program til et spørgsmål om ledelsens ansvarlighed. DORA finder anvendelse fra 17. januar 2025 og giver finansielle enheder et sektorspecifikt regelsæt for digital operationel robusthed i relation til IKT-risiko, hændelsesrapportering, test og tredjepartsrisiko. Cloud, SaaS, administrerede tjenester, administreret sikkerhed, datacentre, indholdsleveringsnetværk, tillidstjenester og udbydere af offentlige elektroniske kommunikationstjenester kan også blive omfattet af direkte eller indirekte forpligtelser afhængigt af omfang, størrelse, sektor, national klassificering og kundekontrakter.

Det praktiske spørgsmål er ikke længere: “Har vi en kontrol?”

Det er: “Hvem ejer kontrollen, hvilken metrik dokumenterer, at den virker, hvor ofte indsamler vi bevismateriale, og hvad sker der, når metrikken fejler?”

Det er kernen i løbende overvågning af efterlevelse for NIS2 og DORA. I Clarysec-implementeringer bruger vi ISO/IEC 27001:2022 som ledelsessystemets fundament, ISO/IEC 27002:2022 som kontrolsprog, Zenith Blueprint: En revisors 30-trins køreplan som implementeringssekvens og Zenith Controls: Vejledningen til tværgående efterlevelse som kompas for tværgående efterlevelse, der forbinder ISO/IEC 27001:2022-bevismateriale med NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 og revisionsforventninger.

Hvorfor NIS2 og DORA gør periodisk efterlevelse utilstrækkelig

NIS2 og DORA er forskellige i retlig struktur, tilsynsmodel og omfang, men de skaber det samme operationelle pres. Cybersikkerhed og IKT-robusthed skal styres løbende.

NIS2 kræver, at væsentlige og vigtige enheder anvender passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger ud fra en all-hazards-tilgang. Disse foranstaltninger omfatter risikoanalyse, sikkerhedspolitikker for informationssystemer, håndtering af hændelser, forretningskontinuitet, krisestyring, sikkerhed i forsyningskæden, sikker anskaffelse og udvikling, håndtering af sårbarheder, vurdering af effektivitet, cyberhygiejne, træning, kryptografi, HR-sikkerhed, adgangsstyring, politik for styring af aktiver og flerfaktorautentificering, hvor det er relevant. Ledelsesorganer skal godkende foranstaltninger til styring af cybersikkerhedsrisici, føre tilsyn med implementeringen og modtage træning.

DORA gør dette endnu mere eksplicit for finansielle enheder. Forordningen kræver interne governance- og kontrolordninger for IKT-risiko, et dokumenteret rammeværk for IKT-risikostyring, ledelsesorganets ansvar, styring og rapportering af IKT-relaterede hændelser, test af digital operationel robusthed, styring af IKT-tredjepartsrisiko, opfølgning på revision, træning og kommunikationsordninger. DORA gør også klart, at finansielle enheder fortsat er ansvarlige for efterlevelse, når de bruger IKT-tredjepartsleverandører.

Det skaber en ny efterlevelsesrealitet. En CISO kan ikke vente til revisionsmåneden med at opdage, at:

• gennemgange af privilegeret adgang er blevet overset i to kvartaler;
• leverandørers exitplaner er dokumenteret, men aldrig testet;
• kriterier for hændelsers alvorlighed ikke er mappet til regulatoriske rapporteringstærskler;
• backups er konfigureret, men bevismateriale for gendannelse mangler;
• ledelsen aldrig har gennemgået forfaldne risikobehandlinger;
• cloudkontrakter mangler revisionsrettigheder, synlighed over underleverandører eller klausuler om hændelsesunderretning.

Den gamle projektbaserede model skaber panikcyklusser. Teams haster før en revision, indsamler skærmbilleder, opdaterer politikdatoer og håber, at bevismaterialet fortæller en sammenhængende historie. NIS2 og DORA er udformet til at få den tilgang til at fejle. De fokuserer på ansvarlighed, proportionalitet, robusthed og bevismateriale for, at kontroller fungerer i praksis.

ISO/IEC 27001:2022 leverer operativsystemet til dette problem. Standardens klausuler kræver, at organisationer forstår kontekst, interessenter, retlige og kontraktlige krav, omfang, ledelse, roller, risikovurdering, risikobehandling, Anvendelseserklæring, operationel planlægning, evaluering af præstation, intern revision, ledelsens gennemgang, håndtering af afvigelser og løbende forbedring. Denne struktur er ideel til at samle NIS2, DORA, GDPR, kundedokumentation og intern risiko i én model for løbende overvågning.

Løbende efterlevelse handler ikke om flere dashboards. Det handler om en styret kadence for bevismateriale.

Byg efterlevelsesmotoren på ISO/IEC 27001:2022

Mange organisationer misforstår ISO/IEC 27001:2022 som alene et certificeringsrammeværk. I praksis er det et risikostyringssystem, der gør sikkerhedsstyring gentagelig, målbar og revisionsbar.

Det er vigtigt, fordi NIS2 og DORA ikke er isolerede tjeklister. De kræver en driftsmodel, der kan absorbere retlige krav, omsætte dem til kontroller, tildele ejerskab, overvåge resultater og forbedre, når der konstateres mangler.

De grundlæggende ISO/IEC 27001:2022-klausuler giver den model:

For en FinTech, SaaS-udbyder, udbyder af administrerede sikkerhedstjenester eller IKT-leverandør til finansielle enheder forhindrer denne struktur overlappende complianceprojekter. Ét ISMS kan kortlægge forpligtelser til kontroller én gang og derefter genbruge bevismateriale på tværs af NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019, ISO/IEC 27001:2022-certificering og kunders assurance-gennemgange.

Start med kontrolejerskab, ikke værktøjer

Det første fejlmønster i løbende efterlevelse er værktøj først-implementering. En virksomhed køber en GRC-platform, importerer hundredvis af krav, tildeler det hele til “sikkerhedsteamet” og kalder det løbende overvågning. Seks måneder senere er dashboardet rødt, engineering bestrider bevismateriale for sårbarheder, juridisk afdeling siger, at leverandørdokumenterne er ufuldstændige, og ledelsen kan ikke se restrisikoen klart.

ISO/IEC 27001:2022 undgår dette ved at kræve, at ansvar og beføjelser tildeles og kommunikeres. NIS2 og DORA styrker samme forventning gennem ledelsesansvar, definerede roller og tilsyn.

Clarysecs Politik for governance-roller og ansvarsområder - SMV fastsætter:

Hver rolle med et sikkerhedsansvar skal registreres i en central log og bekræftes skriftligt.

Den klausul er vigtigere end de fleste dashboards. Hvis backup-test, afhjælpning af sårbarheder, leverandør-due diligence, hændelsesklassificering og gennemgang af privilegeret adgang ikke har navngivne ejere, findes der ingen pålidelig beviskadence.

Informationssikkerhedspolitikken gør dette operationelt for større organisationsmiljøer:

Indsaml og opbevar revisionsbevismateriale til revisioner og kontrolgennemgange.

Den kræver også, at kontrolejere:

Rapporterer kontroludførelse og eventuelle mangler eller forhold til ISMS-ansvarlig.

I Zenith Controls mappes dette emne direkte til ISO/IEC 27002:2022-kontrol 5.2 Roller og ansvar for informationssikkerhed, 5.35 Uafhængig gennemgang af informationssikkerhed og 5.36 Overholdelse af politikker, regler og standarder for informationssikkerhed.

Zenith Blueprint giver et praktisk udgangspunkt i fasen ISMS Foundation & Leadership, trin 4: Roller og ansvar i ISMS’et. Den anbefaler formel udpegning, opdatering af jobbeskrivelser, tilpasning af KPI’er, kommunikation på tværs af organisationen og ansvar på afdelingsniveau.

En typisk udpegningsregistrering kan lyde:

“Med øjeblikkelig virkning udpeges du som informationssikkerhedsansvarlig med ansvar for at føre tilsyn med og koordinere ISMS’et, herunder risikostyring, implementering af kontroller og overvågning af efterlevelse.”

Denne udpegning er ikke bureaukrati. Den er revisionsbevismateriale for ISO/IEC 27001:2022-lederskab og rolletildeling. Den understøtter også NIS2-ledelsestilsyn og DORA-governance. Tilsynsmyndigheder, certificeringsrevisorer og bankkunder vil se, at ansvar ikke er implicit. Det er tildelt, bekræftet, ressourcet og overvåget.

Et praktisk register for kontrolejerskab bør indeholde disse felter:

Dette register bliver broen mellem politik og bevis.

Definér KPI’er og KRI’er, der dokumenterer kontroleffektivitet

Når ejerne er på plads, skal de vide, hvordan “godt” ser ud. Løbende overvågning af efterlevelse drives af meningsfulde indikatorer, ikke brede intentioner.

“ forbedr patchning” er ikke en KPI. “Gennemgå leverandører regelmæssigt” er ikke bevismateriale. “Oprethold robusthed” er ikke en målbar kontrol.

Clarysec skelner klart mellem de to indikatortyper:

• KPI, en nøglepræstationsindikator, måler, om processen fungerer som forventet.
• KRI, en nøglerisikoindikator, signalerer stigende risiko eller en tærskeloverskridelse, der kræver eskalering.

Enterprise-udgaven af Politik for risikostyring fastsætter:

KRI’er (nøglerisikoindikatorer) og sikkerhedsmetrikker skal defineres for kritiske risici og overvåges månedligt.

Den kræver også eskaleringslogik:

Eskalationsudløsere skal indbygges i overvågningslogikken (f.eks. hvor restrisiko stiger med mere end ét niveau, eller frister for behandling overskrides).

For mindre organisationer anvender Clarysecs Politik for risikostyring - SMV en forholdsmæssig tilgang:

Fremdrift på risikoafbødning skal gennemgås kvartalsvist.

Den tillader også letvægtsmetrikker:

Uformelle metrikker kan følges (f.eks. antal åbne risici, forfaldne handlinger, nye hændelser).

Denne proportionalitet er vigtig. En multinational bank og en FinTech-leverandør med 60 medarbejdere behøver ikke identisk telemetri, men begge har brug for tildelt ejerskab, gentagelig måling, eskaleringstærskler og bevismateriale for korrigerende handling.

En praktisk KPI- og KRI-model for NIS2 og DORA ser sådan ud:

Disse metrikker understøtter mere end ISO/IEC 27001:2022-certificering. De understøtter også NIS2-foranstaltninger til styring af cybersikkerhedsrisici, NIS2-beredskab for hændelsesrapportering, DORA IKT-risikostyring, DORA-tredjepartsrisiko, GDPR-ansvarlighed, NIST CSF 2.0-governance-resultater og COBIT-lignende præstationsstyring.

Etablér en beviskadence, før revisionen beder om den

Mange organisationer indsamler bevismateriale tilfældigt. Et skærmbillede dukker op i en Teams-kanal. En Jira-ticket linkes i en e-mail. Et leverandørspørgeskema gemmes hos indkøb. En backuptest beskrives mundtligt. I revisionsugen bliver den ISMS-ansvarlige til digital efterforsker.

Løbende efterlevelse kræver planlagt kadence og god bevishygiejne.

Clarysecs Politik for audit og overvågning af efterlevelse - SMV fastsætter:

Hver revision skal omfatte et defineret omfang, mål, ansvarlige personer og påkrævet bevismateriale.

Den fastsætter også:

Bevismateriale skal opbevares i mindst to år eller længere, hvor det kræves af certificering eller kundeaftaler.

For større organisationer tilføjer Politik for audit og overvågning af efterlevelse forventninger til automatisering:

Automatiserede værktøjer skal udrulles til at overvåge konfigurationsefterlevelse, sårbarhedsstyring, patchstatus og privilegeret adgang.

Automatisering bør være målrettet. Højrisiko- og højfrekvenskontroller bør ikke afhænge af manuelle skærmbilleder. Den bedste bevismodel kombinerer automatiseret telemetri, ejerattesteringer, undtagelseslogge, sagsregistreringer, testresultater og referater fra ledelsens gennemgang.

En navngivningskonvention betyder også noget. Bevismateriale skal kunne fremsøges uden heroisk indsats. For eksempel:

• ugentlig sårbarhedsrapport: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• månedlig gennemgang af privilegeret adgang: YYYY-MM_IAM-Privileged-Review_Attestation
• kvartalsvis leverandørgennemgang: YYYY-QX_Critical-Supplier-Review
• hændelsespakke: INC-YYYY-###_Timeline-Classification-RCA-CAPA

Det er her, politik bliver operationel. Opbevaring af bevismateriale er ikke en arkivopgave. Det er en del af kontrollen.

Map ét bevis til mange forpligtelser

Løbende efterlevelse bliver stærk, når ét bevis kan opfylde flere rammeværker. Derfor er Zenith Controls central i Clarysecs tilgang til tværgående efterlevelse.

Tag håndtering af hændelser som eksempel. Under NIS2 kræver væsentlige hændelser trinvis rapportering, herunder tidlig varsling inden for 24 timer efter kendskab, underretning inden for 72 timer og endelig rapportering inden for én måned, med forbehold for national implementering og hændelsens faktiske forhold. DORA kræver, at finansielle enheder styrer, klassificerer, eskalerer og rapporterer større IKT-relaterede hændelser ved hjælp af krævede processer og skabeloner. GDPR kræver, at dataansvarlige vurderer og håndterer brud på persondatasikkerheden, hvor fortrolighed, integritet eller tilgængelighed af personoplysninger er påvirket.

Én samlet hændelsespakke kan understøtte alle tre, hvis den omfatter:

• hændelsestidslinje og tidspunkt for kendskab;
• begrundelse for klassificering;
• berørte tjenester og jurisdiktioner;
• påvirkning af kunder, transaktioner eller brugere;
• konsekvensvurdering for personoplysninger;
• rodårsag;
• afbødende handlinger og genopretningshandlinger;
• kommunikation og underretninger;
• registrering af ledelseseskalering;
• registrering af korrigerende handling.

Den samme logik for tværgående efterlevelse gælder leverandørrisiko. NIS2 kræver sikkerhed i forsyningskæden og fokus på direkte leverandør- og tjenesteudbyderrelationer. DORA kræver strategi for IKT-tredjepartsrisiko, registre, prækontraktuel due diligence, kontraktlige klausuler, revisionsrettigheder, serviceniveauer, exitstrategier og overvågning af koncentrationsrisiko. NIST CSF 2.0 behandler forsyningskæderisiko som en livscyklusbaseret governance-disciplin. ISO/IEC 27001:2022 binder disse krav sammen i omfang, interessentkrav, risikobehandling og operationel styring af eksternt leverede processer.

En praktisk bevismatrix hjælper kontrolejere med at forstå, hvorfor bevismateriale betyder noget:

Denne tilgang forhindrer dobbelt compliancearbejde. Organisationen indsamler ét stærkt bevismateriale og mapper det derefter til flere forpligtelser.

Clarysecs overvågningsmodel, fra forpligtelse til ejer til bevis

En robust overvågningsmodel følger en enkel sekvens.

Først defineres forpligtelsen. DORA kræver for eksempel, at IKT-tredjepartsrisiko styres som led i IKT-risikostyring med registre, due diligence, kontraktlige krav, revisionsrettigheder og exitstrategier for kritiske eller vigtige funktioner. NIS2 kræver sikkerhed i forsyningskæden og passende korrigerende handling.

Derefter oversættes forpligtelsen til ISO/IEC 27001:2022 ISMS-krav. Det omfatter interessentkrav, omfang, risikovurdering, risikobehandling, Anvendelseserklæring, operationel kontrol, overvågning, intern revision, ledelsens gennemgang og forbedring.

For det tredje vælges operationelle kontroller. I Zenith Controls omfatter centrale governance-kontroller for løbende efterlevelse ISO/IEC 27002:2022-kontrollerne 5.2, 5.35 og 5.36. Understøttende kontroller omfatter ofte 5.19 Informationssikkerhed i leverandørrelationer, 5.21 Styring af informationssikkerhed i IKT-forsyningskæden, 5.22 Overvågning, gennemgang og ændringsstyring af leverandørtjenester, 5.23 Informationssikkerhed ved brug af cloudtjenester, 5.24 Planlægning og forberedelse af styring af informationssikkerhedshændelser, 5.26 Respons på informationssikkerhedshændelser, 5.30 IKT-beredskab for forretningskontinuitet, 5.31 Retlige, lovbestemte, regulatoriske og kontraktlige krav, 8.8 Styring af tekniske sårbarheder, 8.13 Informationsbackup, 8.15 Logning, 8.16 Overvågningsaktiviteter og 8.9 Konfigurationsstyring.

For det fjerde tildeles ejer og kadence. Leverandørrisiko kan involvere indkøb, juridisk afdeling, sikkerhed og den ansvarlige for forretningstjenesten, men én ansvarlig ejer skal vedligeholde registeret og rapportere undtagelser.

For det femte defineres KPI’er, KRI’er og bevismateriale. Leverandør-KPI’er kan omfatte andel af kritiske IKT-leverandører med gennemført due diligence, andel med godkendte kontraktklausuler, antal uden testede exitplaner og antal forfaldne leverandørgennemgange. KRI’er kan omfatte uafklarede leverandørkonstateringer med høj risiko, koncentrationsrisiko over toleranceniveau eller manglende revisionsrettigheder for en tjeneste, der understøtter en kritisk eller vigtig funktion.

For det sjette rapporteres og eskaleres. Månedlige ISMS-dashboards bør ikke blot vise grøn status. De skal identificere forfaldent bevismateriale, risikobevægelse, overskredne behandlingsfrister og ledelsesbeslutninger, der kræves.

For det syvende revideres og forbedres. Huller i bevismateriale bliver til korrigerende handlinger, ikke undskyldninger.

Dette er i overensstemmelse med Zenith Blueprint-fasen Audit, Review & Improvement. Trin 25, Internal Audit Program, anbefaler at dække relevante ISMS-processer og kontroller over revisionscyklussen med en årlig revision af fuldt omfang og mindre kvartalsvise stikprøvekontroller for højrisikoområder, hvor det er relevant. Trin 28, Management Review, kræver input såsom ændringer i krav, overvågnings- og måleresultater, revisionsresultater, hændelser, afvigelser, forbedringsmuligheder og ressourcebehov. Trin 29, Continual Improvement, bruger CAPA-loggen til at registrere problembeskrivelse, rodårsag, korrigerende handling, ansvarlig ejer, måldato og status.

Det er løbende efterlevelse i praksis.

Et praktisk scenarie: kritisk sårbarhed på en offentlig API

Kl. 02.15 udløses en SIEM-alarm. En sårbarhedsscanning har identificeret en kritisk sårbarhed for fjernudførelse af kode på en offentligt tilgængelig API-gateway, der understøtter en reguleret betalingstjeneste.

Modellen for løbende overvågning bør reagere uden at vente på et møde.

Først klassificerer aktivfortegnelsen gatewayen som kritisk. KPI-uret for sårbarhedsstyring starter. KRI’en for upatchede kritiske sårbarheder øges. Hvis aktivet er interneteksponeret, og exploitet er aktivt, udløses eskaleringstærsklen med det samme.

Derefter routes ticketen til DevOps-teamet på vagt. DevOps-chefen modtager, som kontrolejer for sårbarhedsstyring, en automatisk notifikation. SOC Manager følger, om der findes indikatorer på udnyttelse. Den ISMS-ansvarlige overvåger, om hændelseskriterierne er opfyldt.

For det tredje indsamles bevismateriale som et biprodukt af arbejdsgangen. SIEM-alarmen, sårbarhedsscanningen, aktivklassificeringen, tidsstempler fra ticketen, responschatten, patchregistreringen, valideringsscanningen og lukningsgodkendelsen vedhæftes bevispakken.

For det fjerde vurderer teamet, om hændelsen kun er en sårbarhed, en sikkerhedshændelse eller en incident. Hvis der findes servicepåvirkning, kompromitteringsindikatorer, kundepåvirkning eller eksponering af personoplysninger, udløser hændelsesarbejdsgangen vurderinger af rapporteringspligt efter NIS2, DORA, GDPR og kontrakter.

For det femte modtager ledelsen en kortfattet rapport. Hvis sårbarheden blev afhjulpet inden for fire timer, understøtter bevismaterialet kontroleffektivitet. Hvis SLA’en blev overskredet, registrerer CAPA-loggen rodårsag, korrigerende handling, ejer, måldato og status.

Denne ene hændelse genererer nyttigt bevismateriale for sårbarhedsstyring, hændelsesberedskab, overvågning, adgang til kritiske aktiver, ledelsens gennemgang og løbende forbedring.

Hvordan revisorer og tilsynsmyndigheder tester den samme overvågningsmodel

Et modent program for løbende efterlevelse skal kunne bestå forskellige revisionsvinkler. Bevismaterialet ændrer sig ikke, men spørgsmålene gør.

For ISO/IEC 27002:2022-kontrol 5.35 Uafhængig gennemgang af informationssikkerhed vil en ISO/IEC 27001:2022-revisor fokusere på intern revisionsplan, omfang, kompetence, konstateringer og korrigerende handlinger. En NIS2- eller DORA-tilsynsmyndighed vil fokusere på, om ledelsen forstod konstateringerne, finansierede afhjælpning og reducerede systemisk risiko. En NIST CSF 2.0-vurderingspart kan mappe gennemgangen til GOVERN-funktionen, herunder tilsyn og justering af resultater.

Det samme bevismateriale tjener dem alle, hvis det er fuldstændigt, aktuelt og forbundet med ejerskab.

Almindelige faldgruber, der svækker løbende efterlevelse

Den første faldgrube er at behandle NIS2 og DORA som separate projekter. Det skaber duplikerede registre, modstridende metrikker og udmattede kontrolejere. Brug ISO/IEC 27001:2022 som ISMS-fundament, og map forpligtelser gennem ét kontrolbibliotek.

Den anden faldgrube er at tildele kontroller til teams i stedet for personer. “IT ejer backups” er ikke tilstrækkeligt. En navngiven ejer skal attestere, rapportere undtagelser og eskalere risiko.

Den tredje faldgrube er at indsamle bevismateriale uden at evaluere effektivitet. Et skærmbillede af en vellykket backup dokumenterer ikke mulighed for gendannelse. Det gør en gendannelsestest. Et leverandørspørgeskema dokumenterer ikke tredjepartsrobusthed. Kontraktlige klausuler, revisionsrettigheder, vilkår for hændelsesunderretning, resultatrapporter og exitplanlægning skaber stærkere bevismateriale.

Den fjerde faldgrube er at måle aktivitet i stedet for risiko. Det er nyttigt at tælle sårbarheder. Det er bedre at følge forfaldne kritiske sårbarheder på interneteksponerede systemer. Det er nyttigt at tælle leverandører. Det er bedre at følge kritiske leverandører uden exitplaner.

Den femte faldgrube er svag disciplin omkring korrigerende handling. Zenith Blueprint trin 29 er klar: konstateringer kræver problembeskrivelse, rodårsag, korrigerende handling, ansvarlig ejer, måldato og status. Hvis CAPA-loggen ikke gennemgås, bliver løbende efterlevelse til løbende ophobning af kendte svagheder.

Hvad ledelsen bør se hver måned

Ledelsesorganer under NIS2 og DORA har ikke brug for rå scanner-eksporter. De har brug for et beslutningsegnet billede af cyber- og IKT-risiko.

Et månedligt bestyrelses- eller ledelsesdashboard bør omfatte:

• væsentligste cyber- og IKT-risici med bevægelse i restrisiko;
• forfaldne risikobehandlinger og overskredne frister;
• væsentlige hændelser, kandidater til større IKT-relaterede hændelser og læringspunkter;
• kritiske undtagelser vedrørende leverandørrisiko;
• sårbarheds-SLA-resultater for kritiske aktiver;
• status for backup- og gendannelsestest;
• undtagelser fra gennemgang af privilegeret adgang;
• fuldførelsesgrad for efterlevelsesbevismateriale;
• revisionskonstateringer og CAPA-status;
• nødvendige ressourcebeslutninger.

Dette understøtter direkte ISO/IEC 27001:2022 ledelsens gennemgang og governance-forventningerne i NIS2 og DORA. Det er også i overensstemmelse med NIST CSF 2.0, hvor topledere fastsætter prioriteter, ansvarlighed, ressourcer og risikovillighed, mens ledere omsætter disse prioriteter til målprofiler og handlingsplaner.

Byg jeres bevisrytme for NIS2 og DORA i denne uge

I behøver ikke koge havet for at komme i gang. En nyttig første uge kan være enkel.

Dag 1: Opret et register over kontrolejere for fem domæner: governance og risikostyring, hændelsesstyring og rapportering, sårbarheds- og patchstyring, leverandør- og cloudrisiko samt forretningskontinuitet og genopretning.

Dag 2: Definér én KPI og én KRI for hvert domæne. Hold dem specifikke, målbare og knyttet til risikovillighed.

Dag 3: Map hvert bevis til NIS2, DORA, ISO/IEC 27001:2022, GDPR og kundernes assurance-værdi.

Dag 4: Fastlæg beviskadence, lagringsplacering, navngivningskonvention, opbevaringsregel og reviewer.

Dag 5: Gennemfør en tabletop-eskalering. Brug et cloudnedbrud eller et scenarie med en kritisk sårbarhed. Bekræft klassificering, vurdering af regulatorisk rapportering, kundekommunikation, opbevaring af bevismateriale og oprettelse af CAPA.

Hvis jeres organisation stadig styrer NIS2 og DORA med regneark, årlige workshops og spredte bevismapper, er det tid til at skifte til en overvåget driftsrytme.

Start med tre handlinger:

1. Opbyg et register over kontrolejere for jeres domæner med højest risiko.
2. Definér én KPI, én KRI, ét bevis og én kadence pr. kontrol.
3. Gennemfør en 30-minutters gennemgang af bevismateriale, og opret CAPA-punkter for alt, der mangler.

Clarysec kan hjælpe jer med at accelerere skiftet med Zenith Blueprint til implementeringssekvensering, Zenith Controls til kortlægning af tværgående efterlevelse og Clarysecs politikbibliotek, herunder Informationssikkerhedspolitikken, Politik for risikostyring, Politik for audit og overvågning af efterlevelse, Politik for governance-roller og ansvarsområder - SMV, Politik for risikostyring - SMV og Politik for audit og overvågning af efterlevelse - SMV.

Målet er ikke mere compliancepapirarbejde. Målet er at kunne besvare spørgsmålet fredag eftermiddag med sikkerhed:

“Ja, vi ved, hvem der ejer kontrollen, vi kender KPI’en, vi har bevismaterialet, vi kender undtagelserne, og ledelsen har gennemgået risikoen.”

Kontakt Clarysec for at opbygge en model for løbende overvågning af efterlevelse, der er klar til revision, klar til bestyrelsen og robust nok til NIS2, DORA og den næste regulering, der følger.