NIS2 2024/2690: ISO 27001-kartläggning för molnleverantörer

Klockan 08:17 en tisdag tar Maria, informationssäkerhetschef hos en europeisk leverantör av hanterade tjänster, emot det larm som varje MSP fruktar. Ett privilegierat konto för fjärradministration har utlöst ett larm om omöjlig resa. Två kundtenanter visar avvikande administrativa åtgärder. SOC har redan öppnat en brygga för en kritisk incident.

Klockan 09:00 ansluter VD till samtalet. Frågorna förändras omedelbart.

Omfattas vi av NIS2? Gäller kommissionens genomförandeförordning (EU) 2024/2690 för oss? Behöver vi lämna en tidig varning inom 24 timmar? Vilka kunder måste underrättas? Kan vi visa att MFA, loggning, segmentering, sårbarhetshantering, leverantörskontroller och incidenteskalering fungerade före incidenten?

Marias företag är certifierat enligt ISO/IEC 27001:2022. Det levererar molnhantering, datacentertjänster och hanterat säkerhetsstöd till kunder, däribland en logistikleverantör och en regional bank. Certifikatet är viktigt, men det besvarar inte i sig de operativa frågorna. Juridikteamet har ett utkast till aviseringsprocess. Complianceansvarig har ett kalkylblad. Revisorn har begärt Statement of Applicability, testning av incidentrespons, loggar för privilegierad åtkomst, leverantörsgranskningar, underlag för delat ansvar i molnet och antaganden för verksamhetskontinuitet.

Det är här NIS2 upphör att vara en juridisk text och blir ett operativt kontrollproblem.

För molntjänstleverantörer, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster och datacenterleverantörer höjer NIS2 och genomförandeförordning 2024/2690 kraven från allmän säkerhetsambition till verifierbart kontrollunderlag. Styrning, riskhantering, åtkomstkontroll, tillgångshantering, sårbarhetshantering, incidentrespons, leverantörssäkerhet, loggning, övervakning, kryptering, verksamhetskontinuitet och fysisk resiliens måste fungera som ett sammanhållet system.

ISO/IEC 27001:2022 är den bästa ryggraden för detta system, men bara om organisationen kartlägger NIS2-krav till ISMS, riskregister, Statement of Applicability, policyer och evidensmodell. Ett certifikat på väggen räcker inte. Det egentliga arbetet är att bygga en granskningsbar kedja från regelverk till risk, från risk till kontroll, från kontroll till policy och från policy till operativt underlag.

Varför NIS2 2024/2690 förändrar efterlevnadsdiskussionen för moln och MSP

NIS2 använder en modell som kombinerar sektor och storlek, men kategorierna för digital infrastruktur och hantering av IKT-tjänster är avsiktligt breda. Enligt NIS2 Article 2 och Article 3, lästa tillsammans med bilaga I och bilaga II, kan många organisationer klassificeras som väsentliga eller viktiga entiteter, inklusive molntjänstleverantörer, datacentertjänsteleverantörer, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster, DNS-leverantörer, TLD-register, nätverk för innehållsleverans och tillhandahållare av betrodda tjänster. Medlemsstaterna ska upprätta och regelbundet granska förteckningar över väsentliga och viktiga entiteter, med första tidsfristen för förteckningen den 17 april 2025.

Detta är viktigt eftersom molnleverantörer, MSP:er, MSSP:er och datacenterleverantörer ingår i andra organisationers riskkedjor. Ett intrång i ett molnkontrollplan kan påverka tusentals kundsystem. Ett datacenteravbrott kan spridas vidare till bank, hälso- och sjukvård, logistik och offentlig förvaltning. En kompromettering av MSP-inloggningsuppgifter kan bli en ransomware-händelse som drabbar flera kunder. Ett detekteringsfel hos en MSSP kan fördröja begränsning hos reglerade kunder.

NIS2 Article 20 kräver att ledningsorgan godkänner åtgärder för cybersäkerhetsriskhantering och utövar tillsyn över genomförandet. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder baserade på en allriskansats. Baslinjen omfattar riskanalys, incidenthantering, verksamhetskontinuitet, hantering av säkerhet i leveranskedjan, säkerhet vid anskaffning, utveckling och underhåll av nätverks- och informationssystem, sårbarhetshantering och sårbarhetsrapportering, bedömning av effektivitet, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering, MFA eller kontinuerlig autentisering, säker kommunikation och nödkommunikation.

Article 23 lägger till stegvis rapportering av betydande incidenter, inklusive tidig varning inom 24 timmar, incidentanmälan inom 72 timmar, mellanrapporter på begäran och en slutrapport inom en månad efter anmälan eller efter incidenthantering när incidenten fortfarande pågår.

Genomförandeförordning 2024/2690 gör dessa förväntningar mer konkreta för relevanta digitala leverantörer. I praktiken kommer myndigheter, kunder och revisorer inte bara att fråga om policyer finns. De kommer att fråga om kontrollerna är kartlagda, ägda, testade och belagda med underlag.

ISO/IEC 27001:2022 gör NIS2 till operativ ISMS-kontext

Ett vanligt misstag i NIS2-beredskap är att börja med en stor checklista och fördela uppgifter mellan IT, juridik, SOC, infrastruktur, leverantörshantering och compliance. Det kan skapa aktivitet, men faller ofta vid revision eftersom ingen kan visa varför kontroller valdes, hur de relaterar till risk, vem som accepterade kvarstående risk och vilket underlag som visar effektivitet.

ISO/IEC 27001:2022 ger leverantörer strukturen för att undvika detta misslyckande.

Klausulerna 4.1 till 4.4 kräver att organisationen fastställer interna och externa frågor, identifierar intressenter och deras krav, avgör vilka krav som ska hanteras genom ISMS och definierar ISMS-omfattning, inklusive gränssnitt och beroenden. För en moln- eller MSP-leverantör bör omfattningen uttryckligen beakta NIS2, genomförandeförordning 2024/2690, kunders säkerhetsbilagor, DORA-drivna kundkrav, molnregioner, underleverantörer, datacenterberoenden, plattformar för fjärradministration, vägar för privilegierad åtkomst och skyldigheter för incidentanmälan.

Klausulerna 5.1 till 5.3 kräver ledarskap, policyanpassning, resurser, kommunikation, tilldelade ansvar och ledningens ansvarsskyldighet. Detta stödjer direkt NIS2 Article 20.

Klausulerna 6.1.1 till 6.1.3 kräver riskbedömning, riskbehandling, riskägare, analys av sannolikhet och konsekvens, kontrollval, jämförelse med bilaga A, en Statement of Applicability, en riskbehandlingsplan och formell acceptans av kvarstående risk. Det är här NIS2 blir operativt. Varje regulatoriskt krav blir en riskdrivare, ett efterlevnadskrav, ett kontrollkrav eller ett krav på underlag.

Clarysec inleder detta arbete med Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, särskilt riskhanteringsfasen.

Från steg 13, planering av riskbehandling och Statement of Applicability, instruerar Zenith Blueprint team att bygga spårbarhet mellan risker, kontroller och regulatoriska drivkrafter:

”Korsreferera regelverk: Om vissa kontroller införs specifikt för att uppfylla GDPR, NIS2 eller DORA kan du notera detta antingen i riskregistret eller i SoA-anteckningarna. Exempelvis kan kontroll 8.27 (säker radering av data) vara mycket relevant för GDPR:s krav på att radera personuppgifter; du kan notera ’Tillämplig – stödjer GDPR Art.32 (säkerhet i behandlingen)’. Detta krävs inte av ISO, men det hjälper till att visa att ni har beaktat dessa ramverk.”

Steg 14, policyer för riskbehandling och regulatoriska korsreferenser, lägger till den praktiska kartläggningsdisciplinen:

”För varje regelverk, om tillämpligt, kan ni skapa en enkel kartläggningstabell som listar regelverkets viktigaste säkerhetskrav och motsvarande kontroller/policyer i ert ISMS. Detta är inte obligatoriskt enligt ISO 27001, men det är en användbar intern övning för att säkerställa att inget har fallit mellan stolarna.”

Det är skillnaden mellan att säga ”vi är ISO-certifierade” och att visa ”vårt ISO/IEC 27001:2022-ISMS hanterar NIS2:s genomförandeförordning 2024/2690”.

Sammanhållen kontrollkarta från NIS2 till ISO/IEC 27001:2022

Följande kartläggning är inte juridisk rådgivning och ersätter inte analys av nationellt införlivande. Den är en praktisk kontrollarkitektur för leverantörer som behöver en granskningsbar väg från ISO/IEC 27001:2022 till NIS2-beredskap.

Denna kartläggning blir kraftfull när den bäddas in i riskregistret och Statement of Applicability. En leverantör kan till exempel skapa ett riskscenario med namnet ”Kompromettering av plattform för fjärradministration leder till obehöriga åtgärder i kundmiljöer”. Kontrollerna omfattar MFA, privilegierad åtkomsthantering, segmentering, loggning, sårbarhetshantering, leverantörssäkerhet, incidentplanering och rutiner för kundavisering. SoA-anteckningarna kan referera till NIS2 Article 21, Article 23, genomförandeförordning 2024/2690, kundavtal och DORA-relaterade krav på leverantörsgranskning från kunder där det är relevant.

Molnstyrning: ISO-kontroll 5.23 är ett ankare för NIS2

För molnleverantörer och MSP:er som använder molntjänster för att leverera kundtjänster är ISO/IEC 27001:2022 bilaga A kontroll 5.23, Informationssäkerhet vid användning av molntjänster, ett av de viktigaste ankaren.

Zenith Controls: The Cross-Compliance Guide Zenith Controls sammanfattar kontroll 5.23 som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, kopplad till säkerhet i leverantörsrelationer, styrning, ekosystemrisk och skydd. Den omfattar styrning av molntjänster, delat ansvar, leverantörsbedömning, inventeringar, datalagringsplats, loggning, kryptering, identitetsroller, övervakning, avtalsklausuler, leverantörsrisk, molnexit och resiliensplanering.

Zenith Blueprint, fasen Controls in Action, steg 23, förklarar det praktiska skälet:

”Molnet är inte längre en destination, det är standarden. Kontroll 5.23 erkänner denna verklighet och kräver att informationssäkerhet uttryckligen hanteras vid val, användning och hantering av molntjänster – inte som en eftertanke, utan som en designprincip från allra första början.”

För en MSP måste varje plattform för fjärrövervakning och fjärrhantering, kundportal, ärendehanteringssystem, säkerhetstelemetriplattform, säkerhetskopieringstjänst, molnkatalog och SaaS-administrationskonsol omfattas av styrning. För en datacenterleverantör kan molnstyrning gälla övervakningsplattformar, system för besökshantering, integrationer för fysisk åtkomstkontroll, system för fjärradministration och infrastruktur för kundportaler.

Clarysecs Enterprise Cloud Usage Policy Cloud Usage Policy gör leverantörsgranskning före aktivering obligatorisk:

”All användning av molntjänster ska genomgå riskbaserad leverantörsgranskning före aktivering, inklusive leverantörsbedömning, validering av efterlevnad av rättsliga krav och granskning av kontrollvalidering.”

Från avsnittet ”Styrningskrav”, policyklausul 5.2.

För mindre leverantörer skapar Cloud Usage Policy-sme Cloud Usage Policy-sme - SME en lättviktig godkännandemodell:

”All användning av molntjänster ska granskas och godkännas av verkställande chef (GM) före genomförande eller prenumeration.”

Från avsnittet ”Styrningskrav”, policyklausul 5.1.

Båda metoderna stödjer samma NIS2-förväntan: risk kopplad till molnberoenden måste förstås innan tjänsten blir en del av leveranskedjan.

Incidentrespons: 24-timmarsklockan startar innan rapporten skrivs

NIS2 Article 23 är oförlåtande eftersom rapporteringstidslinjen startar när organisationen får kännedom om en betydande incident, inte när en fullständig rotorsaksanalys finns tillgänglig. Utmaningen för leverantörer är att snabbt fastställa om en händelse är betydande, vilka kunder som påverkas, om personuppgifter berörs, om det finns gränsöverskridande påverkan på tjänster och vilka avtalsmässiga tidsfrister som har börjat löpa.

ISO/IEC 27001:2022 bilaga A kontroll 5.24, Planering och förberedelse för informationssäkerhetsincidenthantering, är planeringskontrollen. Zenith Controls sammanfattar den som en korrigerande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet, kopplad till begreppen Respond och Recover, styrning, händelsehantering och försvar. Den omfattar roller, ansvar, eskaleringsvägar, kommunikationsprotokoll, beredskap för regulatorisk avisering, anpassning till loggning och övervakning, integration med verksamhetskontinuitet och katastrofåterställning, lärande efter incidenter och kartläggning till NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 och COBIT 2019.

Clarysecs Incident Response Policy-sme Incident Response Policy-sme - SME gör det första beslutet till ett tidsbundet krav:

”Verkställande chef ska, med stöd från IT-leverantören, klassificera alla incidenter efter allvarlighetsgrad inom en timme från avisering.”

Från avsnittet ”Styrningskrav”, policyklausul 5.3.1.

Denna klassificering inom en timme stödjer den operativa disciplin som behövs för NIS2-analys av tidig varning inom 24 timmar, GDPR-bedömning av personuppgiftsincident, DORA-eskalering till kund och triagering av avtalsmässiga aviseringar.

En leverantörs beslutsträd för incidenter bör besvara fyra frågor:

1. Finns det bekräftad eller misstänkt kompromettering av konfidentialitet, riktighet eller tillgänglighet?
2. Påverkar händelsen tjänsteleverans, kundmiljöer, reglerade kunder, personuppgifter eller kritiska funktioner?
3. Kan den orsaka allvarlig driftstörning, ekonomisk förlust eller materiell eller immateriell skada?
4. Vilka aviseringsskyldigheter gäller: NIS2, GDPR, DORA-kundskyldigheter, avtalsmässiga SLA:er eller nationella tillsynsförväntningar?

Beslutsträdet bör testas i skrivbordsövningar innan en verklig incident inträffar.

Sårbarhetshantering: visa riskreducering före påverkan

NIS2 kräver sårbarhetshantering och sårbarhetsrapportering. För kunder och tillsynsmyndigheter är sårbarhetshantering ett av de enklaste kontrollområdena att mäta eftersom det skapar tydligt underlag: skanningstäckning, patchtider, undantagsgodkännanden, analys av utnyttjade sårbarheter och poster över åtgärdande.

ISO/IEC 27001:2022 bilaga A kontroll 8.8, Hantering av tekniska sårbarheter, sammanfattas i Zenith Controls som en förebyggande kontroll över konfidentialitet, riktighet och tillgänglighet, kopplad till Identify och Protect, hot- och sårbarhetshantering, styrning, ekosystem, skydd och försvar. Den omfattar sårbarhetsidentifiering, bedömning, prioritering, patchning, kompenserande kontroller, integrering av hotinformation, sårbarhetsrapportering, ansvar för sårbarheter i moln och applikationer, revisionsbevis och tidslinjer för åtgärdande.

Clarysecs Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy ger revisorer en konkret modell att testa:

”Organisationen ska klassificera alla upptäckta sårbarheter med en standardiserad metodik (t.ex. CVSS v3.x) och tillämpa åtgärdstider som är anpassade till verksamhetskritikalitet: 5.2.1 Kritisk (CVSS 9.0–10.0): Omedelbar granskning; patchningsfrist om högst 72 timmar. 5.2.2 Hög (7.0–8.9): Respons inom 48 timmar; patchningsfrist om 7 kalenderdagar. 5.2.3 Medel (4.0–6.9): Respons inom 5 dagar; patchningsfrist om 30 kalenderdagar. 5.2.4 Låg (<4.0): Respons inom 10 dagar; patchningsfrist om 60 kalenderdagar.”

Från avsnittet ”Styrningskrav”, policyklausul 5.2.

För en molnleverantör måste detta omfatta hypervisorkomponenter, containeravbildningar, orkestreringslager, kundvända API:er, CI/CD-pipelines, administrativa konsoler och tredjepartsbibliotek. För en MSP är nyckelfrågan om interna sårbarheter skiljs från kundhanterade sårbarheter och om avtal definierar ansvar. För en datacenterleverantör kan omfattningen inkludera fastighetsstyrningssystem, åtkomstkontrollsystem, övervakningsplattformar, verktyg för remote hands och nätverksinfrastruktur.

Modellen för delat ansvar måste dokumenteras. En leverantör äger kanske inte varje patch, men måste ändå hantera risken, underrätta kunden där det är lämpligt och visa att ansvarsgränserna är förstådda.

Loggning, övervakning och segmentering gör incidenter möjliga att utreda

När en leverantörsincident påverkar kunder är de första bevisfrågorna enkla: vem loggade in, varifrån, med vilken privilegienivå, till vilken tenant, vad ändrades, vilka loggar finns och om administrativa vägar var segmenterade.

Clarysecs Enterprise Logging and Monitoring Policy Logging and Monitoring Policy kräver att omfattade system genererar de loggar som incidenthanterare och revisorer behöver:

”Alla omfattade system ska generera loggar som fångar: 6.1.1.1 Användarautentisering och åtkomstförsök 6.1.1.2 Aktiviteter av privilegierade användare 6.1.1.3 Konfigurationsändringar 6.1.1.4 Misslyckade åtkomstförsök eller systemhändelser 6.1.1.5 Detektering av skadlig kod och säkerhetslarm 6.1.1.6 Extern kommunikation och utlösning av brandväggsregler”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

För små och medelstora företag som förlitar sig på externa leverantörer lägger Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME till ett avtalskrav:

”Avtal ska kräva att leverantörer bevarar loggar i minst 12 månader och ger åtkomst på begäran.”

Från avsnittet ”Styrningskrav”, policyklausul 5.5.1.3.

Segmentering är lika viktig. Network Security Policy-sme Network Security Policy-sme - SME anger:

”Interna nätverk ska segmenteras efter funktion (t.ex. ekonomi, gäst, IoT, administrativa system).”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.

Zenith Blueprint, fasen Controls in Action, steg 20, ger det praktiska revisionsförfarandet för nätverksarkitektur och segmentering. Den instruerar team att granska och dokumentera nätverkslayout, verifiera brandväggsregler, IPS/IDS och konfigurationer för fjärråtkomst, bekräfta att säkerhetsgrupper i molnet och VPC- eller subnetregler överensstämmer med avsedd arkitektur, lista interna och externa nätverkstjänster och validera att känsliga system inte kan nås från allmänna användar-VLAN eller gästnätverk.

För en MSP får verktyg för fjärradministration inte ligga platt på kontorsnätverket. För en datacenterleverantör bör administrationsgränssnitt för kraft, kyla, åtkomstkontroll och kundnätverkstjänster isoleras och övervakas. För en molnleverantör bör åtkomst till kontrollplanet begränsas genom identitet, nätverk, enhetsstatus och privilegierade arbetsflödeskontroller.

Leverantörssäkerhet: leverantören är också kund

Molnleverantörer, MSP:er, MSSP:er och datacenterleverantörer är leverantörer till reglerade kunder, men de är också kunder till programvaruleverantörer, teleoperatörer, identitetsleverantörer, SaaS-plattformar, hårdvaruleverantörer, underleverantörer och infrastrukturoperatörer.

NIS2 gör säkerhet i leveranskedjan till ett kärnkrav. DORA, som gäller från den 17 januari 2025, gör IKT-tredjepartsriskhantering central för finansiella entiteter. NIS2 Article 4 och skäl 28 erkänner DORA som den sektorsspecifika unionsrättsakten för finansiella entiteter där kraven överlappar. Detta minskar inte trycket på molnleverantörer och MSP:er. Det ökar det, eftersom finansiella kunder inför DORA-nivåkrav på avtal, revisionsrätt, resiliensprovning, exitstrategier och förväntningar på incidentrapportering i leverantörsavtal.

Clarysecs Enterprise Third party and supplier security policy Third party and supplier security policy kräver kontrollerad tredjepartsåtkomst:

”All tredjepartsåtkomst ska loggas och övervakas och, där det är möjligt, segmenteras via bastionvärdar, VPN:er eller Zero Trust-gateways.”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.3.2.

Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME uttrycker principen om minsta privilegium i direkta termer:

”Leverantörer ska endast ges åtkomst till de minsta system och data som krävs för att utföra sin funktion.”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.1.

Dessa klausuler kartlägger naturligt till ISO/IEC 27001:2022 bilaga A kontrollerna 5.19, 5.20, 5.21 och 5.22. De stödjer också GDPR-styrning av personuppgiftsbiträden och underbiträden, DORA-granskningar av tredjepartsrisk och kunders säkerhetsfrågeformulär.

Verksamhetskontinuitet och datacenterresiliens: bevisa antagandena

NIS2 Article 21 omfattar verksamhetskontinuitet, hantering av säkerhetskopiering, katastrofåterställning och krishantering. DORA Articles 11 till 14 kräver policyer för IKT-verksamhetskontinuitet, respons- och återställningsplaner, Business Impact Analysis, policyer för säkerhetskopiering, återställningsrutiner, återställningsmål, testning, efterincidentgranskningar och kriskommunikation för finansiella entiteter.

För moln- och datacenterleverantörer är kontinuitet inte en pärm. Den består av arkitektur, kapacitet, avtal, beroenden, återställningsunderlag och testade antaganden.

Clarysecs Enterprise Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy kräver årlig BIA och granskning efter väsentliga ändringar:

”Business Impact Analysis (BIA) ska genomföras minst årligen för alla kritiska verksamhetsenheter och granskas vid väsentliga ändringar av system, processer eller beroenden. BIA-resultat ska definiera: 5.2.1. Maximal tolererbar avbrottstid (MTD) 5.2.2. Recovery Time Objectives (RTOs) 5.2.3. Recovery Point Objectives (RPOs) 5.2.4. Kritiska beroenden (system, leverantörer, personal)”

Från avsnittet ”Styrningskrav”, policyklausul 5.2.

I ett datacenterscenario bör BIA omfatta kraftmatningar, UPS, generatorer, bränsleavtal, kyla, brandsläckning, nätoperatörer, system för fysiskt tillträde, remote hands, övervakning, reservhårdvara och kundkommunikationskanaler. I ett molnscenario bör den omfatta regioner, tillgänglighetszoner, replikering, oföränderliga säkerhetskopior, identitetsberoenden, DNS, certifikatutfärdare, API-gateways och supportsystem. I ett MSP-scenario bör den omfatta verktyg för fjärradministration, valv för privilegierad åtkomst, EDR-konsoler, ärendehantering, dokumentarkiv och nödkommunikation.

ISO 22301 kan stärka disciplinen för verksamhetskontinuitetshantering, medan ISO/IEC 27005:2022 stödjer riskkriterier, planering av riskbehandling, övervakning, underlag och ständig förbättring. Detta är användbart eftersom NIS2-beredskap kräver att organisationen samlar rättsliga, avtalsmässiga, operativa, leverantörsrelaterade, tekniska, finansiella, processmässiga och mänskliga faktorer i en riskprocess.

Praktisk riskspårning för ett MSP-intrång via fjärråtkomst

En praktisk workshop kan börja med ett scenario:

”Kompromettering av privilegierad fjärråtkomst leder till obehörig åtkomst till kundsystem, tjänstestörning, möjlig exponering av personuppgifter och regulatoriska aviseringsskyldigheter.”

Skapa en rad i riskregistret och fyll i spårbarheten.

Uppdatera därefter Statement of Applicability. För varje relevant kontroll i bilaga A ska det framgå varför den är tillämplig och vilket NIS2-tema den stödjer. Samla slutligen in underlag före en revision: rapporter om MFA-krav, listor över privilegierade konton, inställningar för logglagring, patchstatus för RMM, SIEM-larm, incidentklassificeringsposter, godkännanden av leverantörsåtkomst och resultat från skrivbordsövningar.

Hur olika revisorer testar samma kontrollmiljö

Ett integrerat ISMS måste tillgodose olika granskningsperspektiv utan att skapa separata evidenspaket för varje ramverk.

Det är här Zenith Controls hjälper som en vägledning för tvärgående efterlevnad. För kontroller som 5.23, 5.24 och 8.8 kopplar den ISO/IEC 27001:2022-kontrollförväntningar till teman i NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF och ISO 22301. Målet är inte att skapa separata efterlevnadsprogram. Målet är en evidensarkitektur som taggas med kontroll, risk, regulatorisk drivkraft och ägare.

Clarysecs genomförandemönster

För molnleverantörer, MSP:er, MSSP:er och datacenterleverantörer bör arbetet gå i fem lager.

Först: bekräfta omfattningen. Fastställ om organisationen och tjänsterna omfattas av NIS2, vilka medlemsstatsregler som gäller, om genomförandeförordning 2024/2690 gäller för leverantörskategorin och om kunder ställer krav enligt DORA, GDPR, NIST eller sektorspecifika regler.

För det andra: bygg ISMS-kontexten. Enligt ISO/IEC 27001:2022 klausulerna 4 och 5 ska intressenter, rättsliga skyldigheter, kundåtaganden, leverantörsberoenden, tjänstegränser och ledningsansvar identifieras.

För det tredje: genomför riskbedömning och riskbehandling enligt principerna i ISO/IEC 27005:2022. Konsolidera NIS2, DORA, GDPR, avtal, interna policyer och tjänsterisker i ett gemensamt register över baslinjekrav. Definiera riskkriterier, ägare, sannolikhet, konsekvens, behandlingsalternativ, kontrollval och godkännanden av kvarstående risk.

För det fjärde: kartlägg kontroller till Statement of Applicability. Använd Zenith Blueprint steg 13 och 14 för att spåra risker till kontroller i bilaga A och regulatoriska förväntningar. Använd Zenith Controls för att förstå hur kontroller som 5.23, 5.24, 8.8, 5.20 och 5.30 kartläggs över ramverk och revisionsperspektiv.

För det femte: operationalisera underlaget. Policyer räcker inte. Clarysecs policybibliotek tillhandahåller avtalsmässigt och operativt tillämpbara krav för molngodkännande, leverantörsåtkomst, loggning, åtgärdande av sårbarheter, nätverkssegmentering, incidentklassificering och kontinuitetsplanering. Evidenspaketet visar att kraven fungerar.

Nästa steg: omvandla NIS2-tryck till resiliens med revisionsberedskap

NIS2:s genomförandeförordning 2024/2690 kräver inte kaos. Den kräver spårbarhet, ägarskap och bevis.

Om du är molntjänstleverantör, MSP, MSSP eller datacenteroperatör, börja med era tjänster, kunder, beroenden, incidentscenarier och skyldigheter att ta fram underlag. Genomför därefter en strukturerad kartläggning från NIS2 till ISO/IEC 27001:2022:

1. Bekräfta om er entitet och era tjänster omfattas.
2. Kartlägg NIS2- och genomförandeförordningens teman till er ISMS-omfattning.
3. Uppdatera riskregister och Statement of Applicability.
4. Tillämpa Clarysec-policyer för molnanvändning, leverantörssäkerhet, loggning, sårbarhetshantering, incidentrespons, nätverkssäkerhet och kontinuitet.
5. Använd Zenith Blueprint Zenith Blueprint steg 13, 14, 20 och 23 för att skapa spårbarhet och operativt underlag.
6. Använd Zenith Controls Zenith Controls för att korskartlägga ISO/IEC 27001:2022-kontroller mot förväntningar enligt NIS2, DORA, GDPR, NIST och COBIT 2019.
7. Testa underlaget genom en revisionssimulering innan en kund, tillsynsmyndighet eller certifieringsrevisor begär det.

Clarysec kan hjälpa er att gå bortom checklistebaserad efterlevnad och bygga ett integrerat ISMS som står emot kravtryck från NIS2, DORA, GDPR och kundrevisioner. Ladda ned relevanta Clarysec-verktygspaket, boka en kartläggningsworkshop eller begär en bedömning av revisionsberedskap för att omvandla regulatorisk komplexitet till försvarbar säkerhetsstyrning och operativ resiliens.