Underlag för NIS2-registrering i ISO 27001:2022

E-postmeddelandet landade i Annas inkorg med ett dämpat ljud som kändes mer som en siren. Som informationssäkerhetschef (CISO) för CloudFlow, en snabbväxande B2B SaaS-leverantör med kunder i hela EU, var hon van vid säkerhetsfrågeformulär, upphandlingsrevisioner och uppföljande ISO 27001-revisioner. Det här meddelandet var annorlunda.

Ämnesraden löd: ”Information Request Regarding National Implementation of Directive (EU) 2022/2555 (NIS2).” Den nationella cybersäkerhetsmyndigheten ville att CloudFlow skulle bekräfta sin klassificering, förbereda registreringsuppgifter för entiteten, identifiera vilka tjänster som omfattades och kunna visa cybersäkerhetsåtgärder för riskhantering.

Anna hade ett ISO 27001:2022-certifikat inramat på väggen. Säljteamet använde det i företagsaffärer. Styrelsen hade godkänt informationssäkerhetspolicyn. Internrevisionen hade nyligen stängt två iakttagelser. Men frågan framför henne var skarpare än certifieringsstatus.

Kunde CloudFlow snabbt och på ett försvarbart sätt visa att dess ISO 27001:2022-ISMS omfattade NIS2-förpliktelserna?

Det är här många organisationer gör fel. De behandlar NIS2-registrering av entitet som en administrativ inlämning, ungefär som att uppdatera ett bolagsregister eller en skatteportal. Det är den inte. Registreringen är dörren in till tillsynsmyndighetens insyn. Efter den dörren kan den behöriga myndigheten begära motivering av omfattning, styrelsens beslutsunderlag, rutiner för incidentrapportering, underlag för leverantörsrisker, kontaktpunkter, mätetal för kontrolleffektivitet och bevis på att organisationen vet vilka tjänster som är kritiska.

För SaaS, moln, hanterade tjänster, hanterad säkerhet, datacenter, digital infrastruktur och vissa leverantörer inom finanssektorn är den verkliga frågan inte längre ”Har vi en säkerhetspolicy?” Den är: ”Kan vi visa en underlagskedja från rättslig skyldighet till ISMS-omfattning, riskbehandling, kontrolldrift och ledningens tillsyn?”

Det starkaste programmet för beredskap inför NIS2-tillämpning är inte ett parallellt kalkylblad. Det är en spårbar underlagsmodell i ISO 27001:2022.

NIS2-registrering är i praktiken en underlagsfråga

NIS2 gäller brett för offentliga och privata entiteter i sektorer som anges i bilaga I och bilaga II och som uppfyller eller överstiger det relevanta tröskelvärdet för medelstora företag. Det omfattar också vissa entiteter oavsett storlek, däribland leverantörer av allmänt tillgängliga elektroniska kommunikationsnät eller kommunikationstjänster, betrodda tjänsteleverantörer, TLD-register, DNS-tjänsteleverantörer, ensamma leverantörer av väsentliga tjänster och entiteter vars störning kan påverka allmän säkerhet, hälsa, systemrisk eller nationell eller regional kritikalitet.

För teknikföretag är de digitala kategorierna särskilt viktiga. Bilaga I omfattar digital infrastruktur, såsom leverantörer av molntjänster, datacentertjänster, innehållsleveransnät, betrodda tjänster, DNS-tjänster och leverantörer av allmänt tillgängliga elektroniska kommunikationsnät eller kommunikationstjänster. Bilaga I omfattar även IKT-tjänstehantering för B2B-tjänster, 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.

Det innebär att en organisation kan hamna inom NIS2-omfattningen utan att se sig själv som ”kritisk infrastruktur”. Ett B2B SaaS-företag med hanterad säkerhetsfunktionalitet, en molnplattform som stödjer reglerade kunder eller en fintech-nära leverantör kan plötsligt behöva en registreringsakt, en kontaktmodell för behörig myndighet och en försvarbar kontrollberättelse.

NIS2 skiljer också mellan väsentliga och viktiga entiteter. Väsentliga entiteter möter normalt en mer proaktiv tillsynsmodell, medan viktiga entiteter vanligtvis blir föremål för tillsyn efter bevis på bristande efterlevnad eller incidenter. Skillnaden är viktig, men den tar inte bort behovet av förberedelse. Båda kategorierna behöver styrning, riskhantering, incidentrapportering, leverantörssäkerhet och underlag.

Finansiella entiteter måste också beakta DORA. NIS2 Article 4 erkänner att när en sektorsspecifik unionsrättsakt ställer minst likvärdiga krav på cybersäkerhetsriskhantering och incidentrapportering, gäller de sektorsspecifika reglerna för motsvarande områden. DORA gäller från den 17 januari 2025 och fastställer IKT-riskhantering, rapportering av större IKT-relaterade incidenter, testning av digital operativ motståndskraft, informationsdelning, IKT-tredjepartsriskhantering, avtalskontroller och tillsyn över kritiska IKT-tredjepartsleverantörer. För omfattade finansiella entiteter är DORA det primära ramverket för cyberresiliens för överlappande krav, men NIS2-gränssnitt och samordning med nationella myndigheter kan fortfarande vara relevanta.

Lärdomen är enkel. Vänta inte på portalfältet eller e-postmeddelandet från tillsynsmyndigheten innan underlag byggs upp. Varje registreringssvar innebär en framtida revisionsfråga.

Börja med ISMS-omfattningen, inte portalformuläret

ISO 27001:2022 är användbar eftersom den tvingar organisationen att definiera kontext, intressenter, regulatoriska skyldigheter, omfattning, risker, riskbehandlingsplaner, kontrolldrift, övervakning, internrevision, ledningens genomgång och förbättring.

Klausulerna 4.1 till 4.4 kräver att organisationen fastställer interna och externa frågor, identifierar intressenter och deras krav, beslutar vilka krav som ska hanteras genom ISMS, definierar ISMS-omfattningen med beaktande av gränssnitt och beroenden, dokumenterar omfattningen och driver ISMS-processerna.

För NIS2 ska denna omfattning besvara praktiska frågor:

• Vilka EU-tjänster, juridiska personer, dotterbolag, plattformar, infrastrukturkomponenter och affärsenheter är relevanta?
• Vilken kategori i bilaga I eller bilaga II kan vara tillämplig?
• Är organisationen väsentlig, viktig, omfattad av DORA, utanför omfattningen eller i avvaktan på nationell klassificering?
• Vilka tjänster är kritiska för kunder, allmän säkerhet, finansiell stabilitet, hälso- och sjukvård, digital infrastruktur eller andra reglerade sektorer?
• Vilka molnleverantörer, MSP:er, MSSP:er, datacenter, underleverantörer och andra leverantörer stödjer dessa tjänster?
• Vilka medlemsstater, behöriga myndigheter, CSIRT:er, dataskyddsmyndigheter och finansiella tillsynsmyndigheter kan vara relevanta?

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint placerar detta arbete tidigt, i steg 2, intressentbehov och ISMS-omfattning. Den instruerar organisationer att identifiera tillsynsmyndigheter och andra myndigheter, granska rättsliga och regulatoriska krav, granska avtal och överenskommelser, genomföra intervjuer med intressenter och beakta förväntade branschstandarder.

Åtgärdspunkt 4.2: Sammanställ en lista över alla betydande intressenter och notera deras krav som rör informationssäkerhet. Var noggrann – tänk på alla som skulle klaga eller drabbas av konsekvenser om er säkerhet brast eller om ni saknade en viss kontroll. Listan vägleder vad ni måste uppfylla eller tillgodose genom ert ISMS och matas in i riskbedömning och kontrollurval.

Det är rätt utgångspunkt för NIS2-registrering. Före inlämning ska organisationen ta fram en kort NIS2-omfattningspromemoria som kopplar verksamhetsmodellen till kategorierna i bilaga I eller bilaga II, dokumenterar antaganden om storlek och tjänster, registrerar tolkning av nationell lag, identifierar behöriga myndigheter och anger om DORA, GDPR, kundavtal eller sektorsregler också gäller.

Clarysecs SME Legal and Regulatory Compliance Policy Policy för rättslig och regulatorisk efterlevnad – SME definierar syftet tydligt:

”Denna policy definierar organisationens metod för att identifiera, uppfylla och visa efterlevnad av rättsliga, regulatoriska och avtalsmässiga skyldigheter.”

För större program är Clarysecs Legal and Regulatory Compliance Policy Policy för rättslig och regulatorisk efterlevnad ännu tydligare:

”Alla rättsliga och regulatoriska skyldigheter ska mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet.”

Den meningen är grunden för beredskap inför tillsyn. Om en tillsynsmyndighet frågar hur NIS2-förpliktelser identifierades ska svaret inte vara ”juridik rådde oss”. Svaret ska vara ett dokumenterat register, kopplat till omfattning, risker, kontrollägare, rutiner, bevarat underlag och ledningens genomgång.

Bygg NIS2-underlagskedjan i ISO 27001:2022

NIS2 Article 21 kräver att väsentliga och viktiga entiteter inför lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för att hantera risker för nätverks- och informationssystem som används för drift eller tjänsteleverans. Åtgärderna ska beakta den senaste utvecklingen, relevanta europeiska och internationella standarder där tillämpligt, kostnad, riskexponering, storlek, sannolikhet och allvarlighetsgrad för incidenter samt samhällelig och ekonomisk påverkan.

Article 21(2) listar minimiområden, inklusive riskanalys och säkerhetspolicyer för informationssystem, incidenthantering, verksamhetskontinuitet, säkerhetskopiering, katastrofåterställning, krishantering, säkerhet i leveranskedjan, säker anskaffning och utveckling, sårbarhetshantering, effektivitetsbedömning, cyberhygien, utbildning, kryptografi, personalsäkerhet, åtkomstkontroll, tillgångshantering, flerfaktorsautentisering eller kontinuerlig autentisering samt säker kommunikation där så är lämpligt.

ISO 27001:2022 mappas naturligt mot denna struktur. Klausulerna 6.1.1 till 6.1.3 kräver riskbedömning och riskbehandling, inklusive kriterier för riskacceptans, riskägare, analys av sannolikhet och konsekvens, en riskbehandlingsplan, jämförelse med Annex A-kontroller och en tillämpbarhetsförklaring. Clause 8 kräver operativ planering och styrning, underlag som visar att processer har fungerat som planerat, ändringsstyrning, kontroll över externt tillhandahållna processer, återkommande riskbedömningar och dokumenterade behandlingsresultat. Clause 9.1 kräver övervakning, mätning, analys och utvärdering. Clause 9.2 kräver internrevision. Clause 10.2 kräver åtgärder vid avvikelser och korrigerande åtgärder.

Clarysecs Risk Management Policy Riskhanteringspolicy – SME omvandlar detta till en operativ regel:

”Alla identifierade risker ska registreras i riskregistret.”

Den övergripande Risk Management Policy Riskhanteringspolicy kopplar riskbehandling till kontrollurval enligt ISO 27001:2022:

”Kontrollbeslut som följer av riskbehandlingsprocessen ska återspeglas i SoA.”

Detta är viktigt eftersom NIS2-underlag ska vara spårbart. Om en myndighet frågar varför en kontroll finns, peka på skyldigheten, risken, behandlingsbeslutet, kontrollägaren, SoA-posten, rutinen och underlaget. Om myndigheten frågar varför en kontroll inte valdes, peka på SoA-motiveringen, godkänd riskacceptans och ledningens genomgång.

Den bästa underlagskedjan är tråkig på bästa möjliga sätt. Varje skyldighet har en ägare. Varje ägare har en kontroll. Varje kontroll har underlag. Varje undantag har godkännande. Varje revisionsiakttagelse har en korrigerande åtgärd.

Gör Article 20-styrning till styrelseunderlag

NIS2 Article 20 flyttar cybersäkerheten in i styrelserummet. Ledningsorgan ska godkänna cybersäkerhetsåtgärder för riskhantering som antas för Article 21, övervaka genomförandet och kan hållas ansvariga för överträdelser. Ledningsorganets medlemmar ska genomgå utbildning, och entiteter uppmuntras att tillhandahålla regelbunden cybersäkerhetsutbildning till anställda.

En styrelse kan inte bara delegera NIS2 till IT. Underlag ska visa att ledningen förstod analysen av NIS2-omfattningen, godkände riskhanteringsmetoden, granskade väsentliga risker, tilldelade resurser, följde upp genomförandet, granskade incidenter och övningar samt fick utbildning.

ISO 27001:2022 klausuler 5.1 till 5.3 stödjer denna styrningsmodell genom krav på högsta ledningens åtagande, anpassning av informationssäkerhetsmål till verksamhetsstrategin, integrering av ISMS-krav i verksamhetsprocesser, resurser, kommunikation, ansvarsskyldighet och rapportering av ISMS-prestanda till högsta ledningen.

Clarysecs Governance Roles and Responsibilities Policy Policy för styrningsroller och ansvar definierar rollen som säkerhetskontakt som en roll som:

”Fungerar som primär kontakt med revisorer, tillsynsmyndigheter och högre ledning i informationssäkerhetsfrågor.”

Den rollen ska namnges i underlagspaketet för NIS2-registrering. Den ska inte vara underförstådd. Myndigheter, revisorer och kunder vill veta vem som samordnar regulatorisk kontakt, vem som äger incidentrapportering, vem som underhåller det rättsliga registret, vem som uppdaterar myndighetskontakter och vem som rapporterar till styrelsen.

En praktisk uppsättning styrningsunderlag omfattar:

• Styrelsens godkännande av ramverket för cybersäkerhetsriskhantering.
• Protokoll från ledningens genomgång som omfattar NIS2-omfattning, risker, incidenter, leverantörer och beredskap.
• Utbildningsloggar för medlemmar i ledningsorganet och anställda.
• En RACI-matris för NIS2-förpliktelser, ISO 27001:2022-kontroller, incidentrapportering, leverantörsförsäkran och regulatorisk kommunikation.
• Underlag som visar att NIS2-förpliktelser ingår i internrevision och övervakning av efterlevnad.
• Uppföljning av korrigerande åtgärder för luckor, försenade risker, undantag och misslyckade tester.

Articles 32 och 33 gör också underlagets kvalitet viktig genom att identifiera faktorer för allvarliga överträdelser, såsom upprepade överträdelser, underlåtenhet att anmäla eller åtgärda betydande incidenter, underlåtenhet att åtgärda brister efter bindande förelägganden, hindrande av revisioner eller övervakning samt felaktig eller grovt oriktig information. Svagt underlag kan bli ett tillsynsproblem även när tekniska kontroller finns.

Förbered underlag för myndighetskontakt och incidentrapportering före 02:00

De mest smärtsamma misslyckandena i incidentrapportering börjar ofta med en enkel fråga: ”Vem ska vi underrätta?” Under ransomware, DNS-avbrott, molnkompromettering eller dataexponering förlorar team tid på att leta efter rätt CSIRT, behörig myndighet, dataskyddsmyndighet, finansiell tillsynsmyndighet, kanal till brottsbekämpande myndighet, kundmall och intern godkännare.

NIS2 Article 23 kräver underrättelse utan onödigt dröjsmål om betydande incidenter som påverkar tjänsteleverans. En betydande incident är en incident som har orsakat eller kan orsaka allvarliga operativa störningar eller finansiell förlust, eller har påverkat eller kan påverka andra genom att orsaka betydande materiell eller immateriell skada. Tidslinjen är stegvis: tidig varning inom 24 timmar från att organisationen fått kännedom, incidentunderrättelse inom 72 timmar, mellanliggande uppdateringar på begäran och en slutrapport inom en månad efter 72-timmarsunderrättelsen eller efter att incidenten hanterats för pågående incidenter. Där det är lämpligt ska tjänstemottagare också informeras om betydande incidenter eller betydande cyberhot och skyddsåtgärder.

Zenith Blueprint, fasen kontroller i drift, steg 22, behandlar kontakt med myndigheter som beredskap, inte panik:

Principen är enkel: om organisationen utsattes för en cyberattack, berördes av en personuppgiftsincident eller blev föremål för en utredning, vem skulle kontakta myndigheterna? Hur skulle personen veta vad som ska sägas? Under vilka förutsättningar skulle sådan kontakt initieras? Dessa frågor måste besvaras i förväg, inte i efterhand.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls omfattar ISO/IEC 27002:2022 kontroll 5.5, kontakt med myndigheter. Den klassificerar kontrollen som förebyggande och korrigerande, kopplad till konfidentialitet, riktighet och tillgänglighet samt till begreppen Identify, Protect, Respond och Recover. Den kopplar också kontroll 5.5 till ISO/IEC 27002:2022-kontrollerna 5.24 planering och förberedelse för hantering av informationssäkerhetsincidenter, 6.8 rapportering av informationssäkerhetshändelser, 5.7 hotinformation, 5.6 kontakt med särskilda intressegrupper och 5.26 respons på informationssäkerhetsincidenter.

Ur ett tvärgående efterlevnadsperspektiv mappar Zenith Controls kontakt med myndigheter till NIS2 Article 23, GDPR-anmälan av personuppgiftsincident, DORA-incidentrapportering, NIST SP 800-53 IR-6 Incidentrapportering och COBIT 2019-praxis för extern eskalering. Ett enda register över myndighetskontakter kan stödja flera skyldigheter om det är korrekt utformat.

Clarysecs Incident Response Policy Policy för incidenthantering – SME gör juridisk triagering uttrycklig:

”När kunddata berörs ska den verkställande chefen bedöma rättsliga underrättelseskyldigheter utifrån tillämpligheten av GDPR, NIS2 eller DORA.”

Ett starkt underlagspaket för myndighetskontakt ska omfatta:

• Kontaktuppgifter till behörig myndighet och CSIRT per medlemsstat och tjänst.
• Kontakter till dataskyddsmyndigheter för GDPR-anmälan av personuppgiftsincident.
• Kontakter till finansiella tillsynsmyndigheter om DORA gäller.
• Kontaktvägar till brottsbekämpande myndigheter och cyberbrottsenheter.
• Behöriga interna kommunikatörer och ersättare.
• Incidenttrösklar för NIS2, GDPR, DORA, kundavtal och cyberförsäkring.
• Mallar för 24-timmars tidig varning, 72-timmarsunderrättelse, mellanliggande uppdatering och slutrapport efter en månad.
• Registreringar från skrivbordsövningar som testar extern underrättelse.
• Poster över tidigare underrättelser, beslut att inte underrätta och juridisk motivering.

Mappa NIS2 Article 21 till ISO 27001-kontroller och policyunderlag

Ett certifikat ensamt besvarar inte en tillsynsmyndighets fråga. En kontrollmappning gör det. Tabellen nedan ger säkerhets- och regelefterlevnadsteam en praktisk brygga mellan områden i NIS2 Article 21, ISO/IEC 27002:2022-kontroller, Clarysecs policyankare och underlag.

Clarysecs Zenith Controls omfattar också ISO/IEC 27002:2022 kontroll 5.31, rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav, som en förebyggande kontroll med påverkan på konfidentialitet, riktighet och tillgänglighet. Den knyter 5.31 till integritet och skydd av PII, bevarande av uppgifter, oberoende granskning och efterlevnad av interna policyer. Den mappar också 5.31 till GDPR:s ansvarsskyldighet, NIS2-efterlevnad i leveranskedjan, DORA IKT-riskhantering, NIST CSF-styrning, NIST SP 800-53-programkontroller och COBIT 2019-tillsyn över extern efterlevnad.

”Kontroll 5.31 säkerställer att alla relevanta rättsliga, regulatoriska, lagstadgade och avtalsmässiga krav som rör informationssäkerhet identifieras, dokumenteras och hanteras kontinuerligt.”

Det är precis vad en nationell myndighet vill se efter registrering: inte bara att NIS2 finns listat, utan att organisationen har en levande mekanism för att identifiera, mappa, genomföra, övervaka och uppdatera skyldigheter.

Separera inte NIS2 från DORA, GDPR, leverantörer och moln

NIS2-underlag finns sällan isolerat.

NIS2 Article 21(2)(d) kräver säkerhet i leveranskedjan, inklusive säkerhetsrelaterade aspekter av relationer med leverantörer och tjänsteleverantörer. Article 21(3) kräver att beslut om leverantörsrisk beaktar sårbarheter, övergripande produktkvalitet, cybersäkerhetspraxis, rutiner för säker utveckling och relevanta samordnade EU-riskbedömningar av leveranskedjan.

ISO 27001:2022 Annex A ger den operativa bryggan genom A.5.19 till A.5.23. För SaaS- och molnorganisationer avgör dessa kontroller ofta om registreringsunderlaget är ytligt eller försvarbart.

DORA skärper leverantörsbilden för finansiella entiteter. Articles 28 till 30 kräver IKT-tredjepartsriskhantering, ett register över IKT-tjänsteavtal, åtskillnad mellan tjänster som stödjer kritiska eller viktiga funktioner, riskbedömning före avtal, leverantörsgranskning, avtalsmässiga säkerhetskrav, revisions- och inspektionsrättigheter, rätt att säga upp avtalet, testade exit-strategier, bedömning av underleverantörer, transparens om datalagringsplats, incidentstöd, samarbete med myndigheter och övergångsarrangemang. Om en SaaS-leverantör betjänar DORA-reglerade kunder kan dess avtal och säkerhetsförsäkranspaket granskas även om den inte själv är den finansiella entiteten.

Clarysecs Third-party and supplier security policy - SME Policy för leverantörssäkerhet och tredjepartssäkerhet – SME ska därför kopplas in i NIS2-underlagspaketet. Leverantörsberedskap ska omfatta:

• Leverantörsförteckning och klassificering av kritikalitet.
• Leverantörsgranskning och riskbedömningar.
• Avtalsklausuler för säkerhet, incidentstöd, revisionsrätt, datalagringsplats, underleverantörer och exit.
• Matriser för delat ansvar i molnet.
• Övervakningsposter för kritiska leverantörer.
• Exit- och återställningstestning för kritiska tjänster.
• Rutiner för leverantörers incidentanmälan och eskalering.

GDPR måste också integreras. En betydande NIS2-incident kan också vara en personuppgiftsincident om kunders, anställdas eller användares data komprometteras. GDPR kräver att personuppgiftsansvariga kan visa ansvarsskyldighet och, när underrättelsetrösklarna är uppfyllda, anmäler till tillsynsmyndigheten inom 72 timmar efter att ha fått kännedom om en personuppgiftsincident. Ert arbetsflöde för incidenthantering måste bedöma NIS2-, GDPR-, DORA-, avtals- och kundskyldigheter parallellt.

Sätt samman ett NIS2-underlagspaket på en vecka

En SaaS-leverantör, MSP, MSSP, molnleverantör eller ett företag inom digital infrastruktur kan göra betydande framsteg på en fokuserad vecka.

Dag 1, klassificera entiteten och tjänsterna. Använd ISMS-omfattningsbeskrivningen och intressentregistret. Lägg till en NIS2-omfattningspromemoria som identifierar kategorier i bilaga I eller bilaga II, EU-tjänster, medlemsstater, kunder, beroenden, storleksantaganden och om DORA eller sektorsregler gäller. Registrera klassificeringsosäkerhet som en risk om den juridiska tolkningen inte är slutlig.

Dag 2, uppdatera registret över rättsliga och regulatoriska skyldigheter. Lägg till NIS2 Articles 20, 21 och 23, registreringskrav enligt nationell rätt, GDPR-skyldigheter vid personuppgiftsincident, DORA-skyldigheter där relevanta och centrala avtalsmässiga underrättelsekrav. Mappa varje skyldighet till en policy, ägare, kontroll, underlagskälla och granskningsfrekvens.

Dag 3, uppdatera riskbedömning och riskbehandling. Inkludera rättslig, regulatorisk, operativ, leverantörsrelaterad, finansiell, anseenderelaterad och samhällelig påverkan i riskkriterierna. Lägg till risker såsom utebliven registrering, felaktig entitetsklassificering, missad 24-timmars tidig varning, otillgängliga myndighetskontakter, leverantörsavbrott som påverkar kritiska tjänster, otillräcklig styrelsetillsyn och oförmåga att styrka kontrolleffektivitet.

Dag 4, uppdatera SoA. Bekräfta NIS2-relevanta kontroller, inklusive A.5.5 kontakt med myndigheter, A.5.19 till A.5.23 leverantörs- och molnkontroller, A.5.24 till A.5.28 incidentkontroller, A.5.29 säkerhet vid störning, A.5.30 IKT-beredskap för verksamhetskontinuitet, A.5.31 rättsliga krav, A.5.34 integritet, A.8.8 hantering av sårbarheter, A.8.13 säkerhetskopiering, A.8.15 loggning, A.8.16 övervakningsaktiviteter, A.8.24 kryptografi och kontroller för säker utveckling A.8.25 till A.8.32.

Dag 5, testa incidentrapportering. Genomför en skrivbordsövning: en felkonfiguration i molnet exponerar kunddata och stör tjänsten i två medlemsstater. Starta klockan. Kan teamet klassificera händelsen, bedöma GDPR-, NIS2-, DORA-, avtals- och kundtrösklar, förbereda en tidig varning inom 24 timmar, utarbeta en 72-timmarsunderrättelse, bevara bevismaterial och tilldela rotorsaksanalys?

Dag 6, samla underlag. Skapa en mapp som är redo för tillsynsmyndigheten med omfattningspromemoria, rättsligt register, riskregister, SoA, kontaktlista för myndigheter, incidentåtgärdsplan, leverantörsregister, styrelseprotokoll, utbildningsloggar, loggar, övervakningsrapporter, säkerhetskopieringstester, sårbarhetsrapporter, internrevisionens omfattning och logg över korrigerande åtgärder.

Dag 7, ledningens genomgång. Presentera beredskapspaketet för ledningen. Registrera godkännanden, kvarstående risker, öppna åtgärder, tidsfrister, resurser och ägarnas ansvarsskyldighet. Om registrering ska ske, bifoga underlagsindexet till registreringsbeslutets dokumentation.

Clarysecs Audit and Compliance Monitoring Policy for SMEs Policy för revision och regelefterlevnadsövervakning – SME förutser detta behov:

”Underlag ska vara anpassat till NIS2-förpliktelser när organisationen har utsetts till viktig entitet eller på annat sätt omfattas av nationell rätt.”

Den övergripande Audit and Compliance Monitoring Policy Policy för revision och regelefterlevnadsövervakning anger målet:

”Att generera försvarbart underlag och ett revisionsspår till stöd för regulatoriska förfrågningar, rättsprocesser eller förfrågningar om säkerhetsförsäkran från kunder.”

Det är målet: försvarbart underlag innan begäran kommer.

Förbered er för olika revisionsperspektiv

En certifieringsrevisor, nationell myndighet, kundrevisor, integritetsrevisor och ett team för leverantörsförsäkran kommer inte att ställa identiska frågor. Ett starkt NIS2-underlagspaket fungerar för dem alla.

För ISO/IEC 27002:2022 kontroll 5.5 förväntar sig revisorer ofta dokumenterade myndighetskontakter, tilldelade ansvar, underhåll av kontakter, åtgärdsplaner för incidenthantering och scenariobaserad tydlighet. En enkel revisionsfråga kan avslöja mognad: ”Vid ransomware, vem kontaktar brottsbekämpande myndighet eller nationell CSIRT?” Om svaret beror på att någon kommer ihåg ett namn är kontrollen inte redo.

Clarysecs Logging and Monitoring Policy Loggnings- och övervakningspolicy – SME förstärker förväntan på underlag:

”Loggar ska vara tillgängliga och begripliga för externa revisorer eller tillsynsmyndigheter på begäran.”

Clarysecs Information Security Policy Informationssäkerhetspolicy anger den bredare organisationsstandarden:

”Alla införda kontroller ska vara möjliga att granska, stödjas av dokumenterade rutiner och bevarat underlag för drift.”

Det är revisionstestet i en enda mening. Om en kontroll inte kan styrkas med underlag väger den inte särskilt tungt när en behörig myndighet begär bevis.

Slutlig checklista för underlag inför NIS2-registrering

Använd denna checklista före registrering eller före svar på en begäran från nationell myndighet.

• Dokumentera analysen av NIS2-omfattningen, inklusive motivering enligt bilaga I eller bilaga II, tjänstebeskrivningar, storleksantaganden, närvaro i medlemsstater och entitetsklassificering.
• Identifiera om DORA gäller direkt eller indirekt genom kunder i finanssektorn och IKT-tjänsteavtal.
• Uppdatera ISMS-omfattningen så att relevanta tjänster, beroenden, outsourcade processer och regulatoriska gränssnitt ingår.
• Lägg till NIS2, GDPR, DORA, sektorsregler och avtalskrav i registret över rättsliga och regulatoriska skyldigheter.
• Mappa varje skyldighet till policyer, kontroller, ägare, underlag, granskningsfrekvens och ledningsrapportering.
• Bekräfta styrelsens godkännande och tillsyn över cybersäkerhetsåtgärder för riskhantering.
• Upprätthåll utbildningsloggar för ledningens och anställdas cybersäkerhetsutbildning.
• Uppdatera riskkriterier så att regulatorisk påverkan, tjänstestörning, kundskada, gränsöverskridande påverkan och leverantörsberoende ingår.
• Registrera NIS2-relaterade risker i riskregistret och koppla dem till behandlingsplaner.
• Uppdatera SoA med NIS2-relevanta Annex A-kontroller och införandestatus.
• Upprätthåll kontaktlistor för myndigheter och underrättelserutiner för CSIRT:er, behöriga myndigheter, dataskyddsmyndigheter, finansiella tillsynsmyndigheter och brottsbekämpande myndigheter.
• Testa arbetsflödet för 24-timmars tidig varning, 72-timmarsunderrättelse, mellanliggande uppdatering och slutrapport efter en månad.
• Upprätthåll underlag för leverantörer och moln, inklusive leverantörsgranskning, avtal, revisionsrätt, övervakning, underleverantörer och exit-planer.
• Styrk kontrolleffektivitet genom loggar, mätetal, revisioner, kontrollpaneler, testresultat och korrigerande åtgärder.
• Förbered ett underlagsindex så att varje begäran från tillsynsmyndighet, kund eller revisor kan besvaras snabbt.

Nästa steg med Clarysec

NIS2-registrering av entitet är inte mållinjen. Det är punkten där organisationen blir synlig för nationell cybersäkerhetstillsyn. Den rätta frågan är inte ”Kan vi registrera oss?” Den rätta frågan är: ”Om myndigheten begär underlag efter registreringen, kan vi då producera en sammanhängande ISO 27001:2022-berättelse på timmar, inte veckor?”

Clarysec hjälper organisationer att bygga den berättelsen genom Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls och praktiska policyuppsättningar för ISO 27001:2022 som kopplar rättsliga skyldigheter, riskbehandling, incidentrapportering, leverantörssäkerhet, loggning, övervakning, revisionsbevis och ledningens ansvarsskyldighet.

Genomför en gap-analys av NIS2-underlag mot ert nuvarande ISMS. Börja med omfattningspromemorian, det rättsliga registret, riskregistret, SoA, kontaktlistan för myndigheter, arbetsflödet för incidentrapportering, leverantörsregistret och mappen med revisionsbevis. Om dessa artefakter är ofullständiga eller frikopplade kan Clarysec hjälpa er att omvandla dem till ett underlagspaket som är redo för tillsynsmyndigheten innan er nationella myndighet frågar.