NIS2-registreringsdokumentation i ISO 27001:2022

E-mailen landede i Annas indbakke med et stille bump, der føltes mere som en sirene. Som CISO i CloudFlow, en hurtigt voksende B2B SaaS-udbyder med kunder i hele EU, var hun vant til sikkerhedsspørgeskemaer, indkøbsrevisioner og ISO 27001-overvågningsrevisioner. Denne besked var anderledes.

Emnelinjen lød: “Anmodning om oplysninger vedrørende national implementering af direktiv (EU) 2022/2555 (NIS2).” Den nationale cybersikkerhedsmyndighed bad CloudFlow bekræfte sin klassificering, forberede oplysninger til enhedsregistrering, identificere de tjenester, der var omfattet, og være klar til at dokumentere cybersikkerhedsrelaterede risikostyringsforanstaltninger.

Anna havde et ISO 27001:2022-certifikat i ramme på væggen. Salgsteamet brugte det i enterprise-aftaler. Bestyrelsen havde godkendt informationssikkerhedspolitikken. Intern revision havde for nylig lukket to observationer. Men spørgsmålet foran hende var skarpere end certificeringsstatus.

Kunne CloudFlow hurtigt og juridisk forsvarligt dokumentere, at virksomhedens ISO 27001:2022-ISMS dækkede NIS2-forpligtelser?

Det er her, mange organisationer tager fejl. De behandler NIS2-enhedsregistrering som en administrativ indberetning på linje med at opdatere et virksomhedsregister eller en skatteportal. Det er den ikke. Registrering er indgangen til synlighed over for tilsynsmyndigheder. Efter denne indgang kan den kompetente myndighed anmode om begrundelse for omfang, registreringer af bestyrelsesgodkendelser, procedurer for hændelsesrapportering, dokumentation for leverandørrisiko, kontaktpunkter, målinger af kontroleffektivitet og dokumentation for, at organisationen ved, hvilke tjenester der er kritiske.

For SaaS-, cloud-, managed service-, managed security-, datacenter-, digital infrastruktur- og visse finanssektorudbydere er det reelle spørgsmål ikke længere “Har vi en sikkerhedspolitik?” Det er “Kan vi vise en sammenhængende dokumentationskæde fra juridisk forpligtelse til ISMS-omfang, risikobehandling, drift af kontroller og ledelsesmæssigt tilsyn?”

Det stærkeste program for NIS2-håndhævelsesberedskab er ikke et parallelt regneark. Det er en sporbar dokumentationsmodel inde i ISO 27001:2022.

NIS2-registrering er i praksis et dokumentationsspørgsmål

NIS2 gælder bredt for offentlige eller private enheder i de sektorer, der er anført i bilag I og bilag II, og som opfylder eller overstiger den relevante tærskel for mellemstore virksomheder. Direktivet omfatter også visse enheder uanset størrelse, herunder udbydere af offentlige elektroniske kommunikationsnet eller -tjenester, tillidstjenesteudbydere, TLD-registre, DNS-tjenesteudbydere, eneleverandører af væsentlige tjenester og enheder, hvis forstyrrelse kan påvirke offentlig sikkerhed, sundhed, systemisk risiko eller national eller regional kritikalitet.

For teknologivirksomheder er de digitale kategorier særligt vigtige. Bilag I omfatter digital infrastruktur, såsom udbydere af cloud computing-tjenester, datacentertjenesteudbydere, udbydere af content delivery-netværk, tillidstjenesteudbydere, DNS-tjenesteudbydere og udbydere af offentlige elektroniske kommunikationsnet eller -tjenester. Bilag I omfatter også IKT-servicestyring for business-to-business-tjenester, herunder managed service providers og managed security service providers. Bilag II omfatter digitale udbydere såsom online markedspladser, online søgemaskiner og platforme for sociale netværkstjenester.

Det betyder, at en organisation kan være omfattet af NIS2 uden at opfatte sig selv som “kritisk infrastruktur”. En B2B SaaS-virksomhed med managed security-funktionalitet, en cloudplatform, der understøtter regulerede kunder, eller en fintech-nær udbyder kan pludselig få behov for en registreringsfil, en kontaktmodel for kompetent myndighed og en dokumenterbar kontrolfortælling.

NIS2 sondrer også mellem væsentlige og vigtige enheder. Væsentlige enheder er generelt underlagt en mere proaktiv tilsynsmodel, mens vigtige enheder normalt først underlægges tilsyn efter dokumentation for manglende efterlevelse eller hændelser. Sondringen har betydning, men den fjerner ikke behovet for forberedelse. Begge kategorier kræver governance, risikostyring, hændelsesrapportering, leverandørsikkerhed og dokumentation.

Finansielle enheder skal også tage DORA i betragtning. NIS2 Article 4 anerkender, at når en sektorspecifik EU-retsakt pålægger mindst tilsvarende forpligtelser til cybersikkerhedsrelateret risikostyring og hændelsesrapportering, gælder de sektorspecifikke regler for de tilsvarende områder. DORA finder anvendelse fra 17. januar 2025 og fastlægger styring af IKT-risiko, rapportering af større IKT-relaterede hændelser, test af digital operationel robusthed, informationsdeling, styring af IKT-tredjepartsrisiko, kontraktlige kontroller og tilsyn med kritiske IKT-tredjepartsudbydere. For omfattede finansielle enheder er DORA den primære ramme for cyberrobusthed for overlappende krav, men NIS2-grænseflader og koordinering med nationale myndigheder kan stadig have betydning.

Læringen er enkel. Vent ikke på portalens felt eller en e-mail fra tilsynsmyndigheden, før dokumentationen opbygges. Ethvert registreringssvar indebærer et fremtidigt revisionsspørgsmål.

Start med ISMS-omfanget, ikke portalformularen

ISO 27001:2022 er nyttig, fordi den tvinger organisationen til at definere kontekst, interessenter, regulatoriske forpligtelser, omfang, risici, behandlingsplaner, drift af kontroller, overvågning, intern revision, ledelsens gennemgang og forbedring.

Klausulerne 4.1 til 4.4 kræver, at organisationen fastlægger interne og eksterne forhold, identificerer interessenter og deres krav, beslutter hvilke krav der håndteres gennem ISMS, definerer ISMS-omfanget under hensyntagen til grænseflader og afhængigheder, dokumenterer dette omfang og driver ISMS-processerne.

For NIS2 bør dette omfang besvare praktiske spørgsmål:

• Hvilke EU-tjenester, juridiske enheder, datterselskaber, platforme, infrastrukturkomponenter og forretningsenheder er relevante?
• Hvilken kategori i bilag I eller bilag II kan finde anvendelse?
• Er organisationen væsentlig, vigtig, omfattet af DORA, uden for omfang eller afventer den national klassificering?
• Hvilke tjenester er kritiske for kunder, offentlig sikkerhed, finansiel stabilitet, sundhedssektoren, digital infrastruktur eller andre regulerede sektorer?
• Hvilke cloududbydere, MSP’er, MSSP’er, datacentre, underleverandører og andre leverandører understøtter disse tjenester?
• Hvilke medlemsstater, kompetente myndigheder, CSIRT’er, datatilsyn og finansielle tilsynsmyndigheder kan være relevante?

Clarysecs Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint placerer dette arbejde tidligt, i trin 2, interessentbehov og ISMS-omfang. Den instruerer organisationer i at identificere tilsynsmyndigheder og øvrige myndigheder, gennemgå juridiske og regulatoriske krav, gennemgå kontrakter og aftaler, gennemføre interessentinterviews og tage forventede branchestandarder i betragtning.

Handlingspunkt 4.2: Udarbejd en liste over alle væsentlige interessenter, og noter deres krav vedrørende informationssikkerhed. Vær grundig – tænk på alle, der ville klage eller blive berørt, hvis jeres sikkerhed svigtede, eller hvis I manglede en bestemt kontrol. Denne liste vil styre, hvad I skal overholde eller opfylde gennem jeres ISMS, og den vil indgå i risikovurdering og kontroludvælgelse.

Det er det rette udgangspunkt for NIS2-registrering. Før indsendelse bør der udarbejdes et kort NIS2-omfangsnotat, som forbinder forretningsmodellen med kategorierne i bilag I eller bilag II, dokumenterer antagelser om størrelse og tjenester, registrerer fortolkning af national ret, identificerer kompetente myndigheder og angiver, om DORA, GDPR, kundekontrakter eller sektorregler også finder anvendelse.

Clarysecs SMV-politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse - SMV definerer formålet klart:

“Denne politik definerer organisationens tilgang til at identificere, opfylde og dokumentere efterlevelse af juridiske, regulatoriske og kontraktlige forpligtelser.”

For større programmer er Clarysecs Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse endnu mere eksplicit:

“Alle juridiske og regulatoriske forpligtelser skal mappes til specifikke politikker, kontroller og ejere inden for ledelsessystemet for informationssikkerhed (ISMS).”

Denne sætning er fundamentet for håndhævelsesberedskab. Hvis en tilsynsmyndighed spørger, hvordan NIS2-forpligtelser blev identificeret, bør svaret ikke være “juridisk afdeling rådgav os”. Svaret bør være et dokumenteret register, knyttet til omfang, risici, kontrolejere, procedurer, opbevaret dokumentation og ledelsens gennemgang.

Opbyg NIS2-dokumentationskæden inde i ISO 27001:2022

NIS2 Article 21 kræver, at væsentlige og vigtige enheder implementerer passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger til at styre risici for net- og informationssystemer, der anvendes til drift eller levering af tjenester. Foranstaltningerne skal tage højde for det aktuelle tekniske niveau, relevante europæiske og internationale standarder, hvor det er relevant, omkostninger, risikoeksponering, størrelse, sandsynlighed for og alvorlighed af hændelser samt samfundsmæssig og økonomisk påvirkning.

Article 21(2) oplister minimumsområder, herunder risikoanalyse og politikker for informationssystemers sikkerhed, hændelseshåndtering, forretningskontinuitet, backups, genopretning efter alvorlige hændelser, 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 aktivstyring, multifaktorautentifikation eller løbende autentifikation samt sikker kommunikation, hvor det er relevant.

ISO 27001:2022 mapper naturligt til denne struktur. Klausulerne 6.1.1 til 6.1.3 kræver risikovurdering og risikobehandling, herunder kriterier for risikoaccept, risikoejere, analyse af sandsynlighed og konsekvens, en risikobehandlingsplan, sammenligning med kontroller i Annex A og en anvendelighedserklæring (SoA). Klausul 8 kræver operationel planlægning og styring, dokumentation for at processer er gennemført som planlagt, ændringsstyring, styring af eksternt leverede processer, tilbagevendende risikovurderinger og dokumenterede behandlingsresultater. Klausul 9.1 kræver overvågning, måling, analyse og evaluering. Klausul 9.2 kræver intern revision. Klausul 10.2 kræver håndtering af afvigelser og korrigerende handling.

Clarysecs Politik for risikostyring Politik for risikostyring - SMV omsætter dette til en driftsregel:

“Alle identificerede risici skal registreres i risikoregisteret.”

Organisationens Politik for risikostyring Politik for risikostyring forbinder risikobehandling med kontroludvælgelse i ISO 27001:2022:

“Kontrolbeslutninger, der følger af risikobehandlingsprocessen, skal afspejles i SoA.”

Det er vigtigt, fordi NIS2-dokumentation bør være sporbar. Hvis en myndighed spørger, hvorfor en kontrol findes, skal der kunne henvises til forpligtelsen, risikoen, behandlingsbeslutningen, kontrolejeren, SoA-posten, proceduren og dokumentationen. Hvis myndigheden spørger, hvorfor en kontrol ikke blev valgt, skal der kunne henvises til SoA-begrundelsen, den godkendte risikoaccept og ledelsens gennemgang.

Den bedste dokumentationskæde er på den gode måde kedelig. Hver forpligtelse har en ejer. Hver ejer har en kontrol. Hver kontrol har dokumentation. Hver undtagelse har godkendelse. Hver revisionsobservation har en korrigerende handling.

Omsæt Article 20-governance til bestyrelsesdokumentation

NIS2 Article 20 flytter cybersikkerhed ind i bestyrelseslokalet. Ledelsesorganer skal godkende de cybersikkerhedsrelaterede risikostyringsforanstaltninger, der vedtages i henhold til Article 21, føre tilsyn med implementeringen og kan holdes ansvarlige for overtrædelser. Medlemmer af ledelsesorganet skal gennemføre træning, og enheder opfordres til at give medarbejdere regelmæssig cybersikkerhedstræning.

En bestyrelse kan ikke blot delegere NIS2 til IT. Dokumentation bør vise, at ledelsen forstod NIS2-omfangsanalysen, godkendte risikostyringstilgangen, gennemgik væsentlige risici, allokerede ressourcer, fulgte implementeringen, gennemgik hændelser og øvelser samt modtog træning.

ISO 27001:2022 klausulerne 5.1 til 5.3 understøtter denne governance-model ved at kræve øverste ledelses forpligtelse, tilpasning af informationssikkerhedsmål til forretningsstrategien, integrering af ISMS-krav i forretningsprocesser, ressourcer, kommunikation, ansvarlighed og rapportering af ISMS-resultater til øverste ledelse.

Clarysecs Politik for governance-roller og ansvarsområder Politik for governance-roller og ansvarsområder definerer rollen som sikkerhedsforbindelse som en, der:

“Fungerer som primært forbindelsesled til revisorer, tilsynsmyndigheder og øverste ledelse i informationssikkerhedsanliggender.”

Denne rolle bør navngives i NIS2-registreringsdokumentationspakken. Den bør ikke være underforstået. Myndigheder, revisorer og kunder vil vide, hvem der koordinerer regulatorisk kontakt, hvem der ejer hændelsesrapportering, hvem der vedligeholder det juridiske register, hvem der opdaterer myndighedskontakter, og hvem der rapporterer til bestyrelsen.

Et praktisk governance-baseret dokumentationssæt omfatter:

• Bestyrelsens godkendelse af ramme for cybersikkerhedsrelateret risikostyring.
• Referater fra ledelsens gennemgang, der dækker NIS2-omfang, risici, hændelser, leverandører og beredskab.
• Træningsregistreringer for medlemmer af ledelsesorganet og medarbejdere.
• En RACI-matrix for NIS2-forpligtelser, ISO 27001:2022-kontroller, hændelsesrapportering, leverandørdokumentation og regulatorisk kommunikation.
• Dokumentation for, at NIS2-forpligtelser indgår i intern revision og overvågning af efterlevelse.
• Sporing af korrigerende handlinger for huller, forfaldne risici, undtagelser og fejlslagne tests.

Articles 32 og 33 gør også kvaliteten af dokumentation vigtig ved at identificere alvorlige overtrædelsesfaktorer såsom gentagne overtrædelser, manglende underretning om eller afhjælpning af væsentlige hændelser, manglende håndtering af mangler efter bindende instrukser, hindring af revisioner eller overvågning samt falske eller groft unøjagtige oplysninger. Svag dokumentation kan blive et håndhævelsesproblem, selv når tekniske kontroller findes.

Forbered myndighedskontakt og dokumentation for hændelsesrapportering før kl. 02:00

De mest smertefulde fejl i hændelsesrapportering starter ofte med et grundlæggende spørgsmål: “Hvem underretter vi?” Under ransomware, DNS-fejl, cloudkompromittering eller dataeksponering mister teams tid på at finde korrekt CSIRT, kompetent myndighed, datatilsyn, finansiel tilsynsmyndighed, kanal til retshåndhævelse, kundeskabelon og intern godkender.

NIS2 Article 23 kræver underretning uden unødig forsinkelse om væsentlige hændelser, der påvirker levering af tjenester. En væsentlig hændelse er en hændelse, der har forårsaget eller kan forårsage alvorlige driftsafbrydelser eller økonomisk tab, eller som har påvirket eller kan påvirke andre ved at forårsage betydelig materiel eller immateriel skade. Tidslinjen er trinvis: tidlig advarsel inden for 24 timer efter, at organisationen er blevet bekendt med hændelsen, hændelsesunderretning inden for 72 timer, mellemliggende opdateringer efter anmodning og en endelig rapport inden for én måned efter 72-timersunderretningen eller efter, at hændelsen er håndteret for igangværende hændelser. Hvor det er relevant, skal tjenestemodtagere også informeres om væsentlige hændelser eller væsentlige cybertrusler og beskyttelsesforanstaltninger.

Zenith Blueprint, fasen Kontroller i praksis, trin 22, behandler kontakt med myndigheder som forberedelse, ikke panik:

Princippet er enkelt: Hvis jeres organisation blev ramt af et cyberangreb, involveret i et brud på persondatasikkerheden eller genstand for en undersøgelse, hvem ville så kontakte myndighederne? Hvordan ville de vide, hvad de skulle sige? Under hvilke betingelser ville sådan kontakt blive iværksat? Disse spørgsmål skal besvares på forhånd, ikke efterfølgende.

Clarysecs Zenith Controls: Vejledning til krydsefterlevelse Zenith Controls dækker ISO/IEC 27002:2022-kontrol 5.5, Kontakt med myndigheder. Den klassificerer kontrollen som forebyggende og korrigerende, knyttet til fortrolighed, integritet og tilgængelighed samt forbundet med begreberne Identify, Protect, Respond og Recover. Den knytter også kontrol 5.5 til ISO/IEC 27002:2022-kontrollerne 5.24 Planlægning og forberedelse af styring af informationssikkerhedshændelser, 6.8 Rapportering af informationssikkerhedshændelser, 5.7 Trusselsintelligens, 5.6 Kontakt med særlige interessegrupper og 5.26 Respons på informationssikkerhedshændelser.

Fra et krydsefterlevelsesperspektiv mapper Zenith Controls kontakt med myndigheder til NIS2 Article 23, GDPR-underretning om brud, DORA-hændelsesrapportering, NIST SP 800-53 IR-6 Incident Reporting og COBIT 2019-praksis for ekstern eskalering. Ét kontaktregister for myndigheder kan understøtte flere forpligtelser, hvis det er udformet korrekt.

Clarysecs Politik for hændelseshåndtering Politik for hændelseshåndtering - SMV gør juridisk triage eksplicit:

“Hvor kundedata er involveret, skal direktøren vurdere juridiske underretningsforpligtelser ud fra anvendelsen af GDPR, NIS2 eller DORA.”

En stærk dokumentationspakke for myndighedskontakt bør omfatte:

• Kontaktoplysninger til kompetent myndighed og CSIRT efter medlemsstat og tjeneste.
• Kontakter til datatilsyn ved GDPR-underretning om brud på persondatasikkerheden.
• Kontakter til finansielt tilsyn, hvis DORA finder anvendelse.
• Kontaktveje til retshåndhævelse og cyberkriminalitet.
• Autoriserede interne kommunikatører og stedfortrædere.
• Hændelsestærskler for NIS2, GDPR, DORA, kundekontrakter og cyberforsikring.
• Skabeloner til 24-timers tidlig advarsel, 72-timers underretning, mellemliggende opdatering og endelig rapport efter én måned.
• Registreringer fra tabletop-øvelser, der tester ekstern underretning.
• Registreringer af tidligere underretninger, beslutninger om ikke at underrette og juridisk begrundelse.

Map NIS2 Article 21 til ISO 27001-kontroller og politikdokumentation

Et certifikat alene besvarer ikke en tilsynsmyndigheds spørgsmål. Det gør en kontrolmapping. Tabellen nedenfor giver sikkerheds- og compliance-teams en praktisk bro mellem områderne i NIS2 Article 21, ISO/IEC 27002:2022-kontroller, Clarysec-politikankre og dokumentation.

Clarysecs Zenith Controls dækker også ISO/IEC 27002:2022-kontrol 5.31, juridiske, lovbestemte, regulatoriske og kontraktlige krav, som en forebyggende kontrol med betydning for fortrolighed, integritet og tilgængelighed. Den knytter 5.31 til privatliv og beskyttelse af personhenførbare oplysninger, opbevaring af registreringer, uafhængig gennemgang og efterlevelse af interne politikker. Den mapper også 5.31 til GDPR-ansvarlighed, NIS2-efterlevelse i forsyningskæden, DORA-styring af IKT-risiko, NIST CSF-styring, NIST SP 800-53-programkontroller og COBIT 2019-tilsyn med ekstern efterlevelse.

“Control 5.31 sikrer, at alle relevante juridiske, regulatoriske, lovbestemte og kontraktlige krav vedrørende informationssikkerhed identificeres, dokumenteres og løbende styres.”

Det er præcis det, en national myndighed ønsker at se efter registrering: ikke blot at NIS2 er oplistet, men at organisationen har en levende mekanisme til at identificere, mappe, implementere, overvåge og opdatere forpligtelser.

Adskil ikke NIS2 fra DORA, GDPR, leverandører og cloud

NIS2-dokumentation eksisterer sjældent isoleret.

NIS2 Article 21(2)(d) kræver sikkerhed i forsyningskæden, herunder sikkerhedsrelaterede aspekter af relationer med leverandører og tjenesteudbydere. Article 21(3) kræver, at leverandørrisikobeslutninger tager højde for sårbarheder, overordnet produktkvalitet, cybersikkerhedspraksis, sikre udviklingsprocedurer og relevante koordinerede EU-risikovurderinger af forsyningskæden.

ISO 27001:2022 Annex A giver den operationelle bro gennem A.5.19 til A.5.23. For SaaS- og cloudorganisationer afgør disse kontroller ofte, om registreringsdokumentationen er overfladisk eller juridisk forsvarlig.

DORA skærper leverandørbilledet for finansielle enheder. Articles 28 til 30 kræver styring af IKT-tredjepartsrisiko, et register over IKT-servicekontrakter, skelnen mellem tjenester, der understøtter kritiske eller vigtige funktioner, risikovurdering før kontraktindgåelse, due diligence, kontraktlige sikkerhedskrav, revisions- og inspektionsrettigheder, ophørsrettigheder, testede exitstrategier, vurdering af underleverandører, gennemsigtighed om datalokation, hændelsesbistand, samarbejde med myndigheder og overgangsordninger. Hvis en SaaS-udbyder betjener DORA-regulerede kunder, kan udbyderens kontrakter og dokumentationspakke blive undersøgt, selv om udbyderen ikke selv er den finansielle enhed.

Clarysecs Politik for tredjeparts- og leverandørsikkerhed - SMV Politik for tredjeparts- og leverandørsikkerhed - SMV bør derfor knyttes til NIS2-dokumentationspakken. Leverandørberedskab bør omfatte:

• Leverandørfortegnelse og klassificering efter kritikalitet.
• Leverandør-due diligence og risikovurderinger.
• Kontraktklausuler om sikkerhed, hændelsesbistand, revisionsrettigheder, datalokation, underleverandører og exit.
• Matricer for delt cloudansvar.
• Overvågningsregistreringer for kritiske udbydere.
• Test af exit og genopretning for kritiske tjenester.
• Procedurer for leverandørunderretning om hændelser og eskalering.

GDPR skal også integreres. En væsentlig NIS2-hændelse kan også være et brud på persondatasikkerheden, hvis kunde-, medarbejder- eller brugerdata kompromitteres. GDPR kræver, at dataansvarlige kan dokumentere ansvarlighed og, hvor underretningstærskler er opfyldt, underrette tilsynsmyndigheden inden for 72 timer efter at være blevet bekendt med et brud på persondatasikkerheden. Jeres arbejdsgang for hændelseshåndtering skal vurdere NIS2-, GDPR-, DORA-, kontraktlige og kundemæssige forpligtelser parallelt.

Sammensæt en NIS2-dokumentationspakke på én uge

En SaaS-udbyder, MSP, MSSP, cloududbyder eller digital infrastrukturvirksomhed kan gøre væsentlige fremskridt på én fokuseret uge.

Dag 1, klassificér enheden og tjenesterne. Brug ISMS-omfangserklæringen og interessentregisteret. Tilføj et NIS2-omfangsnotat, der identificerer kategorier i bilag I eller bilag II, EU-tjenester, medlemsstater, kunder, afhængigheder, størrelsesantagelser og om DORA eller sektorregler finder anvendelse. Registrér klassificeringsusikkerhed som en risiko, hvis den juridiske fortolkning ikke er endelig.

Dag 2, opdatér registeret over juridiske og regulatoriske forpligtelser. Tilføj NIS2 Articles 20, 21 og 23, registreringskrav efter national ret, GDPR-forpligtelser ved brud, DORA-forpligtelser hvor relevante og centrale kontraktlige underretningskrav. Map hver forpligtelse til en politik, ejer, kontrol, dokumentationskilde og gennemgangsfrekvens.

Dag 3, opdatér risikovurdering og behandling. Medtag juridisk, regulatorisk, operationel, leverandørmæssig, finansiel, omdømmemæssig og samfundsmæssig påvirkning i risikokriterierne. Tilføj risici såsom manglende registrering, forkert enhedsklassificering, overskredet 24-timers tidlig advarsel, utilgængelige myndighedskontakter, leverandørnedbrud, der påvirker kritiske tjenester, utilstrækkeligt bestyrelsestilsyn og manglende evne til at dokumentere kontroleffektivitet.

Dag 4, opdatér SoA. Bekræft NIS2-relevante kontroller, herunder A.5.5 kontakt med myndigheder, A.5.19 til A.5.23 leverandør- og cloudkontroller, A.5.24 til A.5.28 hændelseskontroller, A.5.29 sikkerhed under forstyrrelser, A.5.30 IKT-beredskab for forretningskontinuitet, A.5.31 juridiske krav, A.5.34 privatliv, A.8.8 sårbarhedsstyring, A.8.13 backups, A.8.15 logning, A.8.16 overvågningsaktiviteter, A.8.24 kryptografi og kontroller for sikker udvikling A.8.25 til A.8.32.

Dag 5, test hændelsesrapportering. Gennemfør en tabletop-øvelse: En fejlkonfiguration i cloud eksponerer kundedata og forstyrrer tjenesten på tværs af to medlemsstater. Start uret. Kan teamet klassificere hændelsen, vurdere tærskler for GDPR, NIS2, DORA, kontrakter og kunder, forberede en 24-timers tidlig advarsel, udarbejde et udkast til 72-timers underretning, bevare bevismateriale og tildele rodårsagsanalyse?

Dag 6, indsamling af dokumentation. Opret en mappe klar til tilsynsmyndigheden med omfangsnotat, juridisk register, risikoregister, SoA, kontaktliste til myndigheder, hændelsesplaybook, leverandørregister, bestyrelsesreferater, træningsregistreringer, logfiler, overvågningsrapporter, backuptest, sårbarhedsrapporter, omfang for intern revision og log over korrigerende handlinger.

Dag 7, ledelsens gennemgang. Præsenter beredskabspakken for ledelsen. Registrér godkendelser, restrisici, åbne handlinger, frister, ressourcer og ejeransvar. Hvis registrering forfalder, vedlæg dokumentationsindekset til registreringsbeslutningen.

Clarysecs Politik for revision og overvågning af efterlevelse for SMV’er Politik for revision og overvågning af efterlevelse - SMV forudser dette behov:

“Dokumentation skal være tilpasset NIS2-forpligtelser, hvor organisationen er udpeget som en vigtig enhed eller på anden måde falder inden for omfanget af national ret”

Organisationens Politik for revision og overvågning af efterlevelse Politik for revision og overvågning af efterlevelse angiver målet:

“At generere juridisk forsvarlig dokumentation og et revisionsspor til understøttelse af regulatoriske forespørgsler, retssager eller anmodninger fra kunder eller partnere om dokumentation.”

Det er målet: juridisk forsvarlig dokumentation, før anmodningen kommer.

Forbered jer på forskellige revisionsvinkler

En certificeringsrevisor, national myndighed, kunderevisor, databeskyttelsesrevisor og leverandørvurderingsteam stiller ikke identiske spørgsmål. En stærk NIS2-dokumentationspakke fungerer på tværs af dem alle.

For ISO/IEC 27002:2022-kontrol 5.5 forventer revisorer almindeligvis dokumenterede myndighedskontakter, tildelte ansvarsområder, vedligeholdelse af kontakter, playbooks for hændelseshåndtering og scenariebaseret klarhed. Et enkelt revisionsspørgsmål kan afsløre modenhed: “Ved ransomware, hvem kontakter retshåndhævelse eller den nationale CSIRT?” Hvis svaret afhænger af, at nogen husker et navn, er kontrollen ikke klar.

Clarysecs Lognings- og overvågningspolitik Lognings- og overvågningspolitik - SMV understøtter forventningen til dokumentation:

“Logfiler skal være tilgængelige og forståelige for eksterne revisorer eller tilsynsmyndigheder efter anmodning”

Clarysecs Informationssikkerhedspolitik Informationssikkerhedspolitik fastsætter den bredere organisationsstandard:

“Alle implementerede kontroller skal kunne revideres, understøttes af dokumenterede procedurer og have opbevaret dokumentation for drift.”

Det er revisionstesten i én sætning. Hvis en kontrol ikke kan dokumenteres, vil den ikke have stor vægt, når en kompetent myndighed beder om bevis.

Endelig tjekliste for NIS2-registreringsdokumentation

Brug denne tjekliste før registrering eller før svar på en anmodning fra en national myndighed.

• Dokumentér NIS2-omfangsanalysen, herunder begrundelse for bilag I eller bilag II, tjenestebeskrivelser, størrelsesantagelser, medlemsstatsaftryk og enhedsklassificering.
• Identificér, om DORA finder direkte anvendelse eller indirekte gennem finanssektorkunder og IKT-servicekontrakter.
• Opdatér ISMS-omfanget, så det omfatter relevante tjenester, afhængigheder, outsourcede processer og regulatoriske grænseflader.
• Tilføj NIS2, GDPR, DORA, sektorregler og kontraktlige krav til registeret over juridiske og regulatoriske forpligtelser.
• Map hver forpligtelse til politikker, kontroller, ejere, dokumentation, gennemgangsfrekvens og ledelsesrapportering.
• Bekræft bestyrelsens godkendelse og tilsyn med cybersikkerhedsrelaterede risikostyringsforanstaltninger.
• Vedligehold registreringer af cybersikkerhedstræning for ledelse og medarbejdere.
• Opdatér risikokriterier, så de omfatter regulatorisk påvirkning, driftsafbrydelse, kundeskade, grænseoverskridende påvirkning og leverandørafhængighed.
• Registrér NIS2-relaterede risici i risikoregisteret, og knyt dem til behandlingsplaner.
• Opdatér SoA med NIS2-relevante Annex A-kontroller og implementeringsstatus.
• Vedligehold kontaktlister til myndigheder og underretningsprocedurer for CSIRT’er, kompetente myndigheder, datatilsyn, finansielle tilsynsmyndigheder og retshåndhævelse.
• Test arbejdsgangen for 24-timers tidlig advarsel, 72-timers underretning, mellemliggende opdatering og endelig rapport efter én måned.
• Vedligehold leverandør- og clouddokumentation, herunder due diligence, kontrakter, revisionsrettigheder, overvågning, underleverandører og exitplaner.
• Dokumentér kontroleffektivitet gennem logfiler, målinger, revisioner, dashboards, testresultater og korrigerende handlinger.
• Forbered et dokumentationsindeks, så enhver anmodning fra tilsynsmyndighed, kunde eller revisor kan besvares hurtigt.

Clarysecs næste skridt

NIS2-enhedsregistrering er ikke målstregen. Det er punktet, hvor jeres organisation bliver synlig for nationalt cybersikkerhedstilsyn. Det rigtige spørgsmål er ikke “Kan vi registrere os?” Det rigtige spørgsmål er “Hvis myndigheden beder om dokumentation efter registrering, kan vi så levere en sammenhængende ISO 27001:2022-fortælling på timer, ikke uger?”

Clarysec hjælper organisationer med at opbygge den fortælling gennem Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls og praktiske ISO 27001:2022-politiksæt, der forbinder juridiske forpligtelser, risikobehandling, hændelsesrapportering, leverandørsikkerhed, logning, overvågning, revisionsdokumentation og ledelsens ansvarlighed.

Gennemfør en NIS2-gapgennemgang af dokumentation mod jeres nuværende ISMS. Start med omfangsnotatet, det juridiske register, risikoregisteret, SoA, kontaktlisten til myndigheder, arbejdsgangen for hændelsesrapportering, leverandørregisteret og mappen med revisionsdokumentation. Hvis disse artefakter er ufuldstændige eller ikke hænger sammen, kan Clarysec hjælpe jer med at omsætte dem til en dokumentationspakke, der er klar til tilsynsmyndigheden, før den nationale myndighed spørger.